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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the technical realisation for the combination of Circuit Switched calls and IM sessions 
when using them simultaneously between the same two users. 

The present document describes the use of CS and IM services in combination, using the existing procedures that have 
been defined for CS and IMS. It includes the necessary function as adding an IM session to an ongoing CS call, adding 
a CS call to an ongoing IM session, supplementary services as they relate to CSICS and supporting capability exchange. 

The present document is applicable to UE and Application Servers providing for the combination of Circuit Switched 
calls and IM sessions. 



References 



The following documents contain provisions that, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPPTR 21.905: "3G Vocabulary". 

[2] 3GPP TS 22.279: "Combined CS Calls and IMS Sessions". 

[3] 3GPP TS 23.279: "Combining CS and IMS services". 

[4] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[5] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[6] RFC 3840: "Indicating User Agent Capabilities in the Session Initiation Protocol". 

[7] 3GPP TS 22.08 1 : "Line Identification; Service description - Stage 1 " . 

[8] 3GPP TS 22.087: "User-to-User SignalHng (UUS); Service description - Stage 1". 

[9] 3GPP TS 24.087: "User-to-User SignalHng (UUS) Supplementary Service - Stage 3". 

[10] 3GPP TS 24.247: "Messaging service using the IP Multimedia (IM) Core Network; Stage 3". 

[II] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) ; Stage 3". 

[12] 3GPP 33.203: "3G security; Access security for IP-based services ". 

[13] 3GPP TS 26.141 "IP Multimedia System (IMS) Messaging and Presence; Media formats and 

codecs". 

[14] RFC 3264: "An Offer/ Answer Model with Session Description Protocol (SDP) ". 

[15] 3GPP TS 29.162: "Interworking between the IM CN subsystem and IP networks". 

[16] 3GPP TS 29.328: "IP Multimedia (IM) Subsystem Sh interface". 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions are given in 3GPP TS 22.279 [2]. 

Combinational Service 
Combinational call 
Combinational Session 
CSICS capable UE 

For the purposes of the present document, the following terms and definitions are given in 3GPP TS 23.279 [3]. 

CSI session 

Multimedia IMS session 
CSI origination 
CSI termination 
IMS origination 
IMS termination 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [1] apply: 

Universal Subscriber Identity Module (USIM) 
User Equipment (UE) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 33.203 [12] apply: 

IM Subscriber Identity Module (ISIM) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations defined in 3GPP TR 21.905 [1] and the following 
abbreviations apply: 

CSICS Circuit Switched IMS Combinational Service 

4 Common capability information and identifiers for 
CS-first and IMS-first scenarios 

4.1 UE capability exchange - overview 

The terminal capabilities that can be exchanged are: 

a) Media types which can be supported as IMS media streams (i.e. media component definitions of IM sessions); 

b) Media format parameters for supported IMS media types (codecs, media file formats etc.); 

c) MSISDN and preferred SIP URI or tel URI for the UE sending the UE capability information; 

d) Whether the terminal is capable combining an IM session with either CS-Video telephony, CS-Voice, or both; 

e) MMS version that is supported; 

f) Support for other IMS based capabilities and/or services e.g. PoC; and 

g) Personal ME Identifier to identify which of the user"s MEs the UE capability information is related to. 

h) UE capability version, which may be used to identify the current capabilities of a terminal to indicate capability 
update. 
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i) The IM Status, which indicates the IMS capability and registration status of the sending UE. 

3GPP TS 26.141 [13] specifies the 3GPP recommended media formats and codecs which can be reflected in the SDP 
used by the CUA. 

4.2 Personal ME identifier 

A specific ME of the user shall be identified by a personal ME identifier, which has the syntax PMI-XXXX. The part 
"XXXX" shall be a random value, as defined in 3GPP TS 24.008 [4] subclause 2.1.1, in the range from hexadecimal 
0000 to hexadecimal FFFF generated by the CUA. The personal ME identifier shall be stored by the UE and can be 
changed to ensure that two or more of the user's MEs do not have the same personal ME identifier. 

At CS call setup, the MSISDN distinguishes a user and the personal ME identifier distinguishes one ME among those 
belonging to that user. In the IMS, a public user identity distinguishes a user and the personal ME identifier 
distinguishes one ME among those belonging to that user. 

The personal ME identifier may be exchanged during: 

UE capability information exchange; 

IM session set up; and 

- CS call set up. 



4.3 UE capability version 



The UE capability version is used to identify the current UE"s version of capabilities and has the syntax UCV-XX. The 
part 'XX' shall be a value in the range from hexadecimal 00 to hexadecimal FF generated by the CUA, and based on the 
set of capabilities. The UE capability version shall be changed to another value whenever the CUA changes its 
capabilities. 

The UE capability version may be exchanged during: 

UE capability information exchange; 

IM session set up, and 

CS call set up. 

4.4 Radio environment information 

The radio environment information is used to indicate whether the terminal is in a radio environment at CS call 
setup that supports simultaneous use of CS and PS services. 

The radio environment information may be exchanged during CS call setup only. 

4.5 IIVI Status 

The IM Status is exchanged at CS call setup only. The IM Status is only valid for the duration of the CS call. 

The IM Status is an indication of the IMS capability and registration status of the UE that provides this indication. The 
IM Status, if provided, shall indicate the UE as either:- 

not capable of IM subsystem registration 

IM subsystem registered 

IM subsystem capable and willing to register to IM subsystem 

IM subsystem capable but will not register to IM susbsystem 

The IM Status of the UE that provides the IM Status can be used by the receiving CUA in its decision to perform an 
IMS registration if allowed by user's preference (and if the receiving UE is not already IMS registered). 

The provision of the IM Status is optional. 
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5 Common procedures for CS-first and IMS-first 

scenarios 

5.1 Registration of UE capabilities 

The CUA may include a feature tag in the Contact header of a REGISTER request, in accordance with RFC 3840 [6]. 
The feature-tags applicable for CSI are +g.3gpp.cs-voice, +g.3gpp.cs-video, or both values. These feature tags are 
further described in annex A. 

5.2 Criteria for initiating capability exchange 

An OPTIONS request should be sent from the UE to the remote UE in the following cases: 

a) when the UE is in a CS call with the remote UE; and 

the received radio environment information indicates that the remote UE and remote radio environment is 
capable of handling PS and CS domain simultaneously; 

the received MSISDN plus personal ME identifier plus UE capability version does not match any 
combination in use by the UE to cache capabilities; and 

the received IMS status is "MS is IM subsystem registered" or "MS is IM subsystem capable and willing to 
register to IM subsystem". 



b) when the UE is in an IM session with the remote UE and the received INVITE request includes UE capability 
version plus public user identity plus personal ME identifier that does not match any combination in use by the 
UE to cache capabilities. 

NOTE 1: For a CSI call where the CS call is established first, the OPTIONS request can only be sent when the PS 
domain is available. The PS domain can either be available already when the CS call is set-up or at a later 
instant due to changed radio condition. 

c) when the UE capabilities have been significantly upgraded; or 

NOTE 2: A significant upgrade of UE capabilities is when an UE has been upgraded with e.g. video capability or 
supports a new service. 

d) when a UE receives an OPTIONS request from a remote UE and there is no ongoing (or recently finished) 
capability exchange initiated by the UE. 

NOTE 3: The OPTIONS request can be sent as a standalone transaction or as a part of a session. 

Information specific to capability exchange with a CS-call already established is covered in subclause 7.3.1.2. 
Information specific to capability exchange with an IM session already estabhshed is covered in subclause 6.3.1.2. 

5.3 Criteria for responding to a capability exchange request 

The end-user or application shall give its approval for the UE capabilities to be included in response to a capability 
exchange request. 

5.4 Exchange of radio environment information and IIVI Status 

A UE may send information about its current radio environment and its IM Status during CS Call set-up. If the UE finds 
that the remote UE's IM Status indicates the remote UE is either IM subsystem registered or IM subsystem capable and 
willing to register to IM subsystem and its current radio environment supports simultaneous CS and PS services, then if 
allowed by the user"s preference the UE should attempt an IMS registration (if the UE is not already IMS registered). 
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The information exchanged during the call establishment is valid for the duration of the CS call. 

5.5 Storage of capabilities in the UE 

The terminal capabilities of other UEs are stored by the requesting UE. This stored information shall be valid until 
ISIM/USIM is removed or until an update of the terminal capabilities occurs according to subclause 5.2. Stored 
information shall not be deleted when the UE is switched off. 

6 Combining a CS call with an existing IM session 

6.1 Introduction 

(void) 

6.2 Functional entities 

6.2.1 User equipment 

A UE shall implement the role of a CUA as specified in subclause 6.3.1. 

6.2.2 Application server (AS) 

An application server may be included for a CSI call. However, no specific CSI role is assigned to it. 

6.3 Roles 

6.3.1 CSI user agent (CUA) 

6.3.1.1 General 

In addition to the procedures specified in subclause 6.3.1, the CUA shall support the procedures specified in 
3GPP TS 24.229 [5] appropriate to the functional entity in which the CUA is implemented. 

6.3.1 .2 Exchange of UE capability information - IM session first scenario 

When a CUA wants to exchange capabilities with the remote party, the CUA originating the OPTIONS request shall 
apply the procedure as specified in 3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request URI: 

include the URI received in the P-Asserted-Identity header from the remote CUA; or if that is not available: 

include a tel URI corresponding to the MSISDN intended for the CS call set up; or 

include a SIP URI associated with the remote user available in the CUA. 

NOTE 1 : The MSISDN can only be included as a tel URI if it is in international format. 

NOTE 2: If no SIP URI or tel URI in accordance with above is available the CUA cannot initiate the OPTIONS 
request. 

NOTE 3: The OPTIONS request can also be sent as a part of a session. The request URI needs to be set in 
accordance with TS 24.229 [5] in this case. 

b) The CUA shall in the P-Preferred-Identity header either include: 
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- preferably the MSISDN of an assumed registered tel URI of the CUA; or 
an assumed registered SIP URI associated with the CUA. 

c) The CUA shall in the Accept-Contact header include feature tag(s) with the value(s) "+g.3gpp.cs-voice" or 
"+g.3gpp.cs-video" or both, marked as explicit. 

d) The CUA may in the User- Agent header include the personal ME identifier and the UE capability version. Both, 
the personal ME identifier and the UE capability version, shall be present or neither of them. 

The CUA answering with a 200 (OK) response to the OPTIONS request shall apply the procedure as specified in 
3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Contact header include feature tag(s) with the value(s) "+g.3gpp.cs-voice", "+g.3gpp.cs- 
video" or both. The CUA shall include in the Contact header the SIP-URI and, if available the tel URI that can 
be used to establish a CSI call. 

NOTE 4: The indicated tel URI corresponds to the MSISDN intended for the CS call setup. 

b) The CUA may in the Server header include the personal ME identifier and UE capability version. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. 

Upon the receipt of the 200 (OK) response the CUA acts in accordance with 3GPP TS 24.229 [5]. In addition, the CUA 
may locally update the UE capability information, the URIs associated with the remote CUA and the personal ME 
identifier of the remote CUA. 

6.3.1 .3 Session set-up - originating case 

When the originating CUA wants to establish an IM session in combination with a CS call, the CUA shall apply the 
session initiation procedure specified in 3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request-URI in the initial request either include: 

1) a tel URI that is the MSISDN intended for CS call set up; or 

2) a SIP-URI associated with the remote user available in the CUA. 

NOTE: The MSISDN can only be included as a tel URI if it is in the international format. 

b) The CUA shall in the P-Preferred-Identity header in the initial request include an assumed registered tel URI 
corresponding to the MSISDN of the CUA. 

c) The CUA shall in the Accept-Contact header in the initial request include feature tag(s) with the values 
"H-g.3gpp.cs-voice", "H-g.3gpp.cs-video" or both, marked as explicit. 

d) The Contact header shall include feature tag(s) with the value(s) "H-g.3gpp.cs-voice","H-g.3gpp.cs-video" or both. 

e) The CUA may in the User- Agent header include the personal ME identifier and UE capability version. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. 

If the response includes a personal ME identifier and a UE capability version and the combination of public user 
identity plus personal ME identifier plus UE capability version of the terminating UE is known to the CUA, the CUA 
may indicate capability information of the terminating UE to the user via the MMI. 

6.3.1 .4 Session set-up - terminating case 

When the terminating CUA receives an initial request, the terminating CUA shall apply the procedures as specified in 
3GPP TS 24.229 [5]. The Contact header shall include feature tag(s) with the value(s) "H-g.3gpp.cs-voice", "H-g.3gpp.cs- 
video" or both in the response(s), in accordance with RFC 3840 [6]. The UE may include the personal ME identifier and 
UE capability version in the Server header in the responses. Both, the personal ME identifier and the UE capability 
version, shall be present or neither of them. 

If the request includes a personal ME identifier and a UE capability version and the combination of public user identity 
plus personal ME identifier of the originating UE is known to the CUA, the CUA may indicate capability information 
of the originating UE to the user via the MMI. 
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6.3.1 .5 CS call set-up - originating case 

When the originating CUA wants to add the CS part of a CSICS call, it shall set up the call in accordance with 
3GPP TS 24.008 [4] with the following additions: 

a) The CUA may include the radio environment information and the IM Status, the personal ME identifier and UE 
capability version in the user-user information (as defined in 3GPP TS 24.008 [4] Annex O) in the SETUP 
Message. Both, the personal ME identifier and the UE capability version, shall be present or neither of them. The 
handling of the user-user information element shall be in accordance with 3GPP TS 24.087 [9]. 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identity, and the 
UE capability version: 

will not be sent to the remote CUA, 

will be ignored if provided by the remote CUA. 

b) The CUA shall include in the called party BCD number either: 

an E.164 number as included in the P-Asserted-Identity header that was received during IM session 
establishment; or 

if this is not possible, the MSISDN of the remote user stored in UE. 

NOTE 2: It is assumed that the originating CUA uses the COLP supplementary service, in accordance with 
3GPP TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8]. The CLIR 
supplementary service in accordance with 3GPP TS 22.08 1 [7] is not in use in the originating CUA. 

If the connected number received in the CONNECT message differs from the MSISDN number used in the SETUP 
message, the actions to be taken by the CUA are implementation dependent. 

6.3.1 .6 CS call set-up - terminating case 

When the terminating CUA receives a CS call, the CUA shall check if there any ongoing IM sessions, which were 
initiated with a request that included an Accept-Contact header with feature tag(s) with the value(s)"H-g.3gpp.cs-voice", 
"H-g.3gpp.cs-video" or both. 

If there are ongoing IM sessions, which were initiated with a request that included an Accept-Contact header 
with feature tag(s) with the values(s)"H-g.3gpp.cs-voice, "H-g.3gpp.cs-video" or both and if the received Calling 
Party BCD number corresponds to an entry in the P-Asserted-Identity header in an ongoing IM session, the CUA 
shall set up the call in accordance with 3GPP TS 24.008 [4]. The CUA may include the user-user information 
element with the radio environment information, the IM Status, personal ME identifier (as defined in 
3GPP TS 24.008 [4] Annex O) and UE capability version in the CONNECT message, in accordance with 
3GPP TS 24.087 [9]. Both, the personal ME identifier and the UE capability version, shall be present or neither 
of them. 

Otherwise, the CUA shall set up the call in accordance with subclause 7.3.1.6. 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identifier and the 
UE capability version: 

will not be sent to the remote CUA, 

will be ignored if provided by the remote CUA. 

NOTE 2 It is assumed that the terminating CUA uses the CLIP supplementary service, in accordance with 
3GPP TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8] The COLR 
supplementary service in accordance with 3GPP TS 22.081 [7] is not in use in the terminating CUA. 

NOTE 3: If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identifier and UE 
capability version will not be sent to the remote CUA. 
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6.3.1 .7 SDP exchange - UE capability information exchange 

The CUA shall act in accordance with 3GPP TS 24.229 [5] when the CUA exchanges its capabilities with the remote 
CUA. 

The following information may be included: 

a) Media types which can be supported as IMS media streams (i.e. media component definitions of IM sessions). 

b) Media format parameters for supported IMS media types (codecs, media file formats etc.). 
NOTE: The media and codecs used for the CS call are not included in the SDP. 

6.3.1 .8 SDP offer answer - originating case 

When a CUA wants to create a CSI communication, the CUA shall populate the SDP as specified in subclause 6.1 in 
3GPPTS 24.229 [5]. 

6.3.1 .9 SDP offer answer - terminating case 

When a CUA wants to participate in a CSI communication, the CUA shall populate the SDP as specified in 
subclause 6.1 in 3GPP TS 24.229 [5]. 



7 Combining an IIVI session with an existing CS call 

7.1 Introduction 

(void) 

7.2 Functional entities 

7.2.1 User equipment 

A UE shall implement the role of a CUA as specified in subclause 7.3.1. 

7.2.2 Application server (AS) 

An application server may be included for a CSI call. However, no specific CSI role is assigned to it. 

7.3 Roles 

7.3.1 CSI user agent (CUA) 

7.3.1.1 General 

In addition to the procedures specified in subclause 7.3.1 of this document, the CUA shall support the procedures 
specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the CUA is implemented. 

7.3.1 .2 Exchange of UE capability information - CS first scenario 

When the CUA wants to exchange capabilities with the remote party, the CUA originating the OPTIONS request shall 
apply the procedure as specified in3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request URI include one of the following: 
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a URI, as received in P-Asserted-Identity header from the remote CUA during the terminal capability 
information exchange procedure; or, if this is not available; 

a tel URI consisting of the Connected Number information element or the Calling Party BCD number 
received during establishment of the existing CS call, or the MSISDN used for the CS call set-up ( the Called 
Party BCD Number); or 

a SIP URI associated with the remote user stored in the CUA. 

NOTE 1 : The MSISDN can only be included as a tel URI if it is in the international format. 

NOTE 2: If no SIP URI or tel URI in accordance with above is available the CUA cannot initiate the OPTIONS 
request. 

b) The CUA shall in the P-Preferred-Identity header either include: 

the MSISDN of the CUA as an assumed registered tel URI; or 
an assumed registered SIP URI associated with the CUA. 

c) The CUA shall in the Accept-Contact header include feature tag(s) with the values(s) "+g.3gpp.cs-voice", 
"+g.3gpp.cs-video" or both marked as explicit. 

d) The CUA may in the User- Agent header include the personal ME identifier and the UE capability version. Both, 
the personal ME identifier and the UE capability version, shall be present or neither of them. 

The CUA answering with a 200 (OK) response to the OPTIONS request shall apply the procedure as specified in 
3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Contact header include feature tag(s) with the values(s) "H-g.3gpp.cs-voice", "H-g.3gpp.cs- 
video" or both. The CUA shall include in the Contact header the SIP-URI and, if available the tel URI that can 
be used to establish a CSI call. 

NOTE 3: The indicated tel URI corresponds to the MSISDN intended for the CS call setup. 

b) The CUA may in the Server header include the personal ME identifier and the UE capability version. Both, the 
personal ME identifier and the UE capability version, shall be present or neither of them. 

Upon the receipt of the 200 (OK) response, the CUA acts in accordance with 3GPP TS 24.229 [5]. In addition, the CUA 
may locally update the UE capability information for the remote user, the URIs associated with the remote CUA and the 
personal ME identifier of the remote CUA. 

7.3.1 .3 Session set-up - originating case 

When the originating CUA wants to add an IM session to a CS call, it shall apply the call initiation procedure specified 
in 3GPP TS 24.229 [5] with the following additions: 

a) The CUA shall in the Request URI in the initial request either include: 

1) the URI, as received in P-Asserted Identity header from the terminating CUA during the terminal capability 
information exchange procedure; or if this is not available 

2) a tel URI that either is: 

- the connected number information element, received during establishment of the existing CS call, and if 
this is not available the MSISDN used for the CS call set-up (the used Called Party BCD Number); or 

the Calling Party BCD number information element, received during establishment of the existing CS 
call. 

b) The CUA shall in the P-Preferred Identity header in the initial request include an assumed registered tel URI 
corresponding to the MSISDN of the CUA. 

c) The CUA shall in the Accept-Contact header in the initial request include feature tag(s) with the value(s) 
'H-g.3gpp.cs-voice', a 'H-g.3gpp.cs-video' or both, marked as explicit. 
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d) The Contact header shall include feature tag(s) with the value(s) "+g.3gpp.cs-voice","+g.3gpp.cs-video" or both. 

e) The CUA may in the User- Agent header include the personal ME identifier and the UE capability version. Both, 
the personal ME identifier and the UE capability version, shall be present or neither of them. 

NOTE 1 : If privacy is indicated it is not possible to correlate the CS call and the IM session. 

7.3.1 .4 Session set-up - terminating case 

When the terminating CUA receives an initial request for an IM session, the terminating CUA shall apply the 
procedures as specified in 3GPP TS 24.229 [5] with the following additions: 

a) If the Accept-Contact header in the INVITE request includes in a feature tag(s) with the value(s)"+g.3gpp.cs- 
voice", "+g.3gpp.cs-video" or both, the CUA shall check if one of the identities in the P-Asserted-Identity header 
matches the received Calling Party BCD number information element or Connected number information element 
received for an ongoing CS call. If there is a match, a CSICS call is established. 

Otherwise, the CUA shall not consider this a CSI call/session. 

b) The Contact header shall include feature tag(s) with the value(s) "+g.3gpp.cs-voice", "+g.3gpp.cs-video" or both 
in the response(s), in accordance with RFC 3840 [6]. 

c) The UE may include the personal ME identifier and the UE capability version in the Server header in the 
responses. Both, the personal ME identifier and the UE capability version, shall be present or neither of them. 

7.3.1 .5 CS call set-up - originating case 

When the originating CUA wants to set up a CS call in combination with an IM Session, the CUA shall set up the call 
in accordance with 3GPP TS 24.008 [4] with the following additions: 

a) The SETUP message may include the user-user information element, which can include the radio environment 
information, the IM Status, the personal ME identifier and the UE capability version as specified in 
3GPP TS 24.008 [4] Annex O. Both, the personal ME identifier and the UE capability version, shall be present 
or neither of them. The handling of the user-user information element shall be in accordance with 

3GPPTS 24.087 [9]. 

If the CONNECT message includes a personal ME identifier and UE capability version and the combination of 
MSISDN plus personal ME identifier plus UE capability version of the terminating UE is known to the CUA, the CUA 
may indicate already available capability information of the terminating UE to the user via the MMI. If originating UE 
finds that terminating UE and its current radio environment supports simultaneous CS and PS services and terminating 
UE's IM Status indicates the remote UE is either IM subsystem registered or IM subsystem capable and willing to 
register to IM subsystem, then if allowed by the user"s preference originating UE should attempt an IMS registration (if 
the UE is not already IMS registered). 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 22.087 [8] the radio environment information, the IM Status, the personal ME identifier and the 
UE capability version: 

will not be sent to the remote CUA, 

will be ignored if provided by the remote CUA. 

NOTE 2: It is assumed that the originating CUA uses COLP supplementary service, in accordance with 
3GPP TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8] The CUR 
supplementary service in accordance with 3GPP TS 22.08 1 [7] is not in use in the originating CUA. 

7.3.1 .6 CS call set-up - terminating case 

When the terminating CUA receives a CS call: 

a) the CUA shall set up the call in accordance with 3GPP TS 24.008 [4] and may include the user to user 
information element in the CONNECT message with the radio environment information, the IM Status, the 
personal ME identifier and the UE capability version as defined in 3GPP TS 24.008 [4] Annex O. Both, the 
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personal ME identifier and the UE capability version, shall be present or neither of them. The handling of the 
user-user information element shall be in accordance with 3GPP TS 22.087 [8]. 

If the SETUP message includes a personal ME identifier and UE capability version and the combination of MSISDN 
plus personal ME identifier plus UE capability version of the originating UE is known to the CU A, the CUA may 
indicate already available capability information of the originating UE to the user via the MMI. If terminating UE finds 
that originating UE and its current radio environment supports simultaneous CS and PS services and originating UE's 
IM Status indicates the remote UE is either IM subsystem registered or IM subsystem capable and willing to register to 
IM subsystem, then if allowed by the user"s preference terminating UE should attempt an IMS registration (if the UE is 
not already IMS registered). 

NOTE 1 : If the CUA does not support the user-to-user 1 supplementary service, in accordance with 

3GPP TS 24.087 [9] the radio environment information, the IM Status, the personal ME identifier and the 
UE capability version: 

will not be sent to the remote CUA 

will be ignored if provided by the remote CUA. 

NOTE 2: It is assumed that the terminating CUA uses the CLIP supplementary service, in accordance with 3GPP 
TS 22.081 [7] and UUS service 1, in accordance with 3GPP TS 22.087 [8]. The COLR supplementary 
service in accordance with 3GPP TS 22.081 [7] is not in use in the terminating CUA. 

7.3.1 .7 SDP exchange - UE capability information exchange 

The CUA shall act in accordance with subclause 6.3.1.7. 

7.3.1 .8 SDP offer-answer - originating case 

The CUA shall act in accordance with subclause 6.3.1.8. 

7.3.1 .9 SDP offer-answer - terminating case 

The CUA shall act in accordance with subclause 6.3.1.9. 



8 Interaction with supplementary services 

No protocol interactions for supplementary services are identified. 
NOTE: Service interactions are specified in 3GPP TS 23.279 [3]. 



IIVIS origination and CSI termination 



9.1 Introduction 

This subclause describes the detailed procedures for establishing sessions from UEs that use IMS origination to UEs 
that use CSI termination. 

NOTE: The IMS origination and CSI termination are specific session establishment scenarios defined in TS 
23.279 [3]. When a UE is considered to use IMS origination and when a UE is considered to use CSI 
termination is defined in subclause 9.2.1. 
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9.2 Functional entities 

9.2.1 User equipment 

For establishing sessions with IMS origination and CSI termination, two different UEs are involved. 

1) The UE that uses CSI termination, which terminates sessions by receiving real time media over the CS 
domain. This UE implements the role of CUA as specified in subclause 6.3.1 and subsclaue 7.3.1. 

2) The UE that uses IMS origination, which originates sessions by transmitting real time and non-real time 
media over an IP-CAN. 

9.2.2 Application server (AS) 

For supporting the control functionality required to handle sessions with IMS origination and CSI termination an 
application server shall implement the role of CSI AS as defined in subclause 9.3.3. 

9.2.3 IVIGCF 

Editor" s Note: The need for MGCF interworking support to enable transportation of CSI capability information is 
FES. 

9.3 Roles 

9.3.1 General 

9.3.2 CSI UA (CUA) 

The UE that uses CSI termination implements the role of CUA as specified in subclause 6.3.1 and subsclaue 7.3.1 with 
no additional requirements. 

NOTE: For proper handling and delivery of CSI terminating sessions, a CUA needs to include the media feature 
tags applicable for CSI in the Contact header when performing the registration procedure. 

9.3.3 CSI AS 

9.3.3.1 General 

The CSI AS shall support the procedure for the multimedia session splitting, modifying, combining and releasing. 

The CSI AS may use the feature tags (e.g. "H-g.3gpp.cs-voice" and "H-g.3gpp.cs-video") obtained from the terminating 
CUA to perform termination logic including the following: 

if the feature tags indicate that the CUA has both voice and video capabilities, then the CSI AS will use the CS 
domain to terminate any realtime voice and video sessions to the CUA; or 

if the feature tags indicate that the CUA only has the voice capability, then the CSI AS will use the CS domain to 
terminate only the realtime voice session to the CUA. 

If no feature tags or other information that may influence the handling of session termination are available to the CSI 
AS, then the CSI AS splits the multimedia session. 

The procedure of multimedia session splitting is specified in the subclause 9.3.3.4 and subclause 9.3.3.5. 

NOTE: The CSI AS obtains the feature tags of the terminating CUA from the reg-event package. 
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9.3.3.2 3rd Party Registration 

When the CSI AS upon receiving a third party REGISTER request responds to it with the SIP 200 OK response 
successfully, the CSI AS may subscribe 'reg-event' in order to obtain a list of all the registered public user identities of 
the user including implicitly registered public user identities. A list of the public user identities can also be provided by 
the HSS. 

NOTE: It is assumed that the CUA includes the feature tag in Contact header during the registration to trigger the 
third-party REGISTER to the CSI AS. 

9.3.3.3 Session Splitting towards terminating CUA 

9.3.3.3.1 General 

The CSI AS performs the session splitting and session combining to the third party registered CUA. 

When the CSI AS receives the SIP INVITE request including the SDP media descriptions for both voice media and 
non-voice media(e.g. MSRP) from the originating UE, the CSI AS shall check if there are any ongoing sessions 
between the originating UE and the terminating CUA. 

1) if there are no ongoing IM sessions between the originating UE and the terminating CUA, the CSI AS performs 
the session splitting procedure as follows: 

a) for the non-voice media, the CSI AS shall initiate the new SIP INVITE requesting the same non-voice media 
towards the CUA via IM CN subsystem as per subclause 9.3.3.4 and, 

b) for the voice media, the CSI AS shall initiate the new SIP INVITE requesting the same voice media towards 
the CUA via CS domain through the MGCF as per subclause 9.3.3.5. 

Editor" s Note: If the CUA is not registered to the IM CN subsystem, the CSI AS would not have been triggered. In 
this case, how the the SIP INVITE from the originating UE is to be handled is FFS. 

2) if there is an ongoing IM session between the originating UE and the terminating CUA, the CSI AS shall follow 
the subclause 9.3.3.6. 

When the CSI AS receives the SIP INVITE request including the SDP media description for voice media only, the CSI 
AS shall check if there are any ongoing IM sessions between the originating UE and the terminating CUA. 

1) if there is no ongoing IM session between the originating UE and the terminating CUA, the CSI AS shall follow 
the subclause 9.3.3.4 or, 

2) Otherwise the CSI AS shall follow the subcaluse 9.3.3.6. 

When the CSI AS receives the SIP INVITE request including the SDP media description for non-voice media only, the 
CSI AS shall check if there are any ongoing IM sessions between the originating UE and the terminating CUA. 

1) if there are no ongoing IM session between the originating UE and the terminating CUA, the CSI AS shall 
follow the subclause 9.3.3.5 or, 

2) Otherwise the CSI AS shall follow the subcaluse 9.3.3.6. 

9.3.3.3.2 Call Initiation towards the CS domain 

When the CSI AS receives an initial SIP INVITE request that requests an IMS session with voice media, the CSI AS 
shall perform the third party call control, as specified 5.7.5 of 3GPP TS 24.229[5] including the following: 

1) The CSI AS creates the SIP INVITE request setting the Request-URI and To header to a Tel-URI which is an 
alias of the SIP-URI which is included in the received SIP INVITE request. 

NOTE: The CSI AS maps between SIP-URI and Tel-URI from information provided by the HSS about aUas 
URIs of the registered identity, as specified in 3GPP TS 29. 328 [16] . 

2) The CSI AS adds the address of BGCF in the Route header to be located behind of the address of S-CSCF. 
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3) The CSI AS populates the SDP with the voice media parameters which is included in the SIP INVITE from the 
originating UE. 

4) The CSI AS sends the SIP INVITE towards the S-CSCF for further routeing. 

If the CSI AS does not take any action for the received SIP INVITE, it shall apply the procedure described in subclause 
5.7.4 of 3GPP TS 24.229 [5]. 

9.3.3.3.3 Session Initiation towards the IMS domain 

If the received INVITE includes the SDP media parameter for non-voice media, the CSI AS decides whether it 
performs the third party call control. 

NOTE: Whether the CSI AS performs the third party call control can be pre-configured in the CSI AS based on 
the policy of the network operator, or it can be configured based on the information of the received SIP 
INVITE request. 

If the CSI AS performs the third party call control, it shall apply the procedure described in subclause 5.7.5 of 3GPP TS 
24.229 [5] including the following: 

1) The CSI AS creates the SIP INVITE with the same Request-URI as received from the UE. 

2) The CSI AS populates the SDP with the non-voice media parameters which is included in the SIP INVITE from 
the originating UE. 

3) The CSI AS sends the SIP INVITE towards the S-CSCF for further routeing. 

If the CSI AS does not take any action for the received INVITE, it shall apply the procedure described in subclause 
5.7.4 of 3GPPTS 24.229 [5]. 

9.3.3.4 Session Modification 

9.3.3.4.1 Adding an IM Session to an existing CS call 

When the CSI AS receives a SIP re-INVITE request and the received SDP includes a new "m=" line which does not 
include "audio" and has non-zero port number, the CSI AS shall initiate a SIP INVITE request requesting the same non- 
voice media towards the CUA in the IM CN subsystem as specified in the subclause 9.3.3.2.1. 

When the CSI AS receives the SIP response message from the CUA, it shall be processed according to the subclause 
9.3.3.5. 

9.3.3.4.2 Adding a CS call to an existing IMS Session 

When the CSI AS receives a SIP re-INVITE request and the received SDP includes an additional "m=audio" line which 
has non-zero port; 

the CSI AS shall check if there is an ongoing voice call between the CUA and the CSI AS which is associated 
with the same session in which the SIP re-INVITE request is received, 

a) If a voice call between the CUA and the CSI AS via CS domain does not exist, the CSI AS shall initiate a SIP 

INVITE requesting the same voice media towards the CUA in CS domain via MGCF as specified in the 
subclause 9.3.3.2 or, 

b) Otherwise, the CSI AS shall reply with 4xx response. 
NOTE: The multicall setup is not supported within this specification. 

When the CSI AS receives the SIP response from the MGCF, it shall be processed according to the subcaluse 9.3.3.5. 

9.3.3.4.3 Modifying an existing CS call and an existing IMS Session 

When the CSI AS receives a SIP re-INVITE request and there is ongoing session for corresponding media between the 
CSI AS and the CUA which is associated with the session in which the SIP re-INVITE request is received. 
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1) if the SDP media description for voice in the received SIP re- INVITE request is updated, 

a) the CSI AS shall initiate the SIP re-INVITE request including the updated SDP media description in the 
dialog that is established toward the MGCF and, 

b) When the CSI AS receives the SIP response from the MGCF, it shall be processed according to the subcaluse 
9.3.3.5. 

2) if the SDP media description for non-voice in the received SIP re-INVITE request is updated, 

a) the CSI AS shall initiated the SIP re-INVITE request including the updated SDP media description in the 
dialog that is established toward the CUA in the IM CN subsystem and, 

b) When the CSI AS receives the SIP response from the CUA, it shall be processed according to the subcaluse 
9.3.3.5. 

3) if the SDP media description in the received SIP re-INVITE request includes one or more "m=" lines with the 
port number set to zero, the CSI AS shall remove the corresponding media in the associated session between the 
CSI AS and the CUA as specified in the subclause 9.3.3.6. 

9.3.3.5 Session Combining 

The CSI AS having established on call leg to the CUA and another call leg to the MGCF, shall combine the responses 
from the CUA and the MGCF as follows; 

The CSI AS shall act as a B2BUA as per subclause 5.7.5 of 3GPP TS 24.229 [5] with the following additions. 

The CSI AS shall respond to the SIP INVITE request from the originating UE when the CSI AS receives the first SDP 
answer from both of the two call legs toward the CUA. The SIP response code that is sent to the originating UE by the 
CSI AS depends on the SIP response received from the two call legs. 

When the CSI AS receives the SIP responses for the SIP INVITEs request that were sent to the CUA and the MGCF, 
the CSI AS shall; 

1) provide the SIP response to the originating UE as per subclause 5.7.5 of 3GPP TS 24.229 [5]. In this SIP response 

except the final response, the CSI AS shall provide all SDP media description that is received from the CUA and 
the MGCF in the SDP answer. 

2) provide the combined final SIP response to the originating UE only if the final SIP responses arrive from the each 

of the two call legs, 

9.3.3.6 Session Release 

If the CSI AS receives the SIP re-INVITE request which includes part of "m=" lines with the port number set to zero in 
the SDP from the originating UE, then; 

1) if the received SDP media description includes "m=audio" line with the port number set to zero, the CSI AS 
initiates a SIP BYE request to release the session toward the MGCF which is associated with the session where 
the SIP re-INVITE is received or, 

2) if part of port numbers of "m=" lines other than "m=audio" in the received SDP media description is zero, the 
CSI AS initiates a SIP re-INVITE request including SDP media description for non-voice toward the CUA or, 

3) if all of port numbers of "m=" lines other than "m=audio" in the received SDP media description is zero, the CSI 
AS initiates aSIP BYE request towards the CUA in the IM CN subsystem. 

If the CSI AS receives the SIP BYE request from the originating UE, then; 

1) the CSI AS shall initiate the SIP BYE request to release the session towards the CUA which is associated to the 

session where the SIP BYE request is received and, 

2) the CSI AS shall initiate the SIP BYE request to release the session towards the MGCF which is associated to the 

session where the SIP BYE request is received. 

If the CSI AS recevices the SIP BYE request from the CUA or the MGCF, then; 
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1) if there is no remaining session other than the session the SIP BYE request belongs to, the CSI AS initiates a SIP 
BYE request toward the originating UE or, 

2) otherwise, the CSI AS initiates a SIP Re-INVITE request to remove corresponding media toward the originating 
UE. 
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Annex A (normative): 

Media feature tags defined within the current document 

A.1 General 

This subclause describes the media feature tag definitions that are applicable for the 3GPP IM CN Subsystem for the 
realisation of CSI. 

Editor"s note: The media feature tag values defined in this Annex need lANA registration. 

A.2 Definition of "+g.3gpp.cs-voice" 

Media feature-tag name: +g.3gpp.cs-voice. 

ASN.l Identifier: New assignment by lANA. 

Summary of the media feature indicated by this tag: This feature-tag indicates that the device supports circuit switched 
voice when combining circuit switched calls and IM sessions. 

Values appropriate for use with this feature-tag: Boolean. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: 

This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as 
a phone or PDA. 

Examples of typical use: Indicating that a mobile phone can support voice in a circuit switched environment within the 
context of combining a circuit switched voice call with an IM session. 

Related standards or documents: 

3GPP TS 24.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services, stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 11.1 of 
RFC 3840 [6]. 

A.3 Definition of "+g.3gpp.cs-video" 

Media feature-tag name: H-g.3gpp.cs-video. 

ASN. 1 Identifier: New assignment by lANA. 

Summary of the media feature indicated by this tag: This feature-tag indicates that the device supports circuit switched 
video when combining circuit switched video calls and IM sessions. 

Values appropriate for use with this feature-tag: Boolean. 

The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation 
mechanisms: 

This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as 
a phone or PDA. 

Examples of typical use: Indicating that a mobile phone can support video in a circuit switched environment within the 
context of combining a circuit switched video call with an IM session. 



ETSI 



3GPP TS 24.279 version 7.4.0 Release 7 24 ETSI TS 1 24 279 V7.4.0 (2007-03) 

Related standards or documents: 

3GPP TS 24.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services, stage 3" 

Security Considerations: Security considerations for this media feature-tag are discussed in subclause 11.1 of 
RFC 3840 [6]. 
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Annex B (informative): 

Example signalling flows for the combining of CS calls with 

IM sessions 

B.1 Scope of signalling flows 

This annex gives examples of signalling flows for the combination of CS calls with IM sessions within the IP 
Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP). 

These detailed signalling flows expand on the overview information flows provided in 3GPP TS 23.279 [3]. 



B.2 Introduction 
B.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [11]. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [11] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no combining of CS calls with IM sessions functionality 
associated with this hiding, and therefore such separate signalling flows are not show in the present document; 

b) 3GPP TS 24.228 [11] breaks down the functionality of the various CSCFs. Such intervening activity in the 
CSCFs is in general not relevant to showing the functionality combining of CS calls with IM sessions, and 
therefore the CSCFs are collapsed into a single entity labelled "Intermediate IM CN subsystem entities". 

B.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [11] subclause 4.1 applies with the additions 
specified below: 

- tel:+12125551 1 1 1 is the tel URI, PMI-0007 is the personal ME identifier and UCV-04 is the UE capability 
version relating to CUA#1; 

- tel:+12125552222 is the tel URI, PMI-0EA2 is the personal ME identifier and UCV-OD is the UE capability 
version relating to CUA#2; 

- tel:+12125553333 is the tel URI of the UE#1 and 

- sip:user3_pubHcl @homel .net is the SIP URI of the UE#1 . 



Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [11]. 

However, 3GPP TS 24.228 [11] includes extensive descriptions for the contents of various headers following each of 
the tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown 
in 3GPP TS 24.228 [11], then such text is not reproduced in the present document. 

Additional text can also be found on the contents of headers within 3GPP TS 24.228 [11] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the following notation is used: 
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INVITE 



SETUP 



-► SIP message 

-► CS message 

►- Media over a PS connection 



Media over a CS connection 



Figure B.2.2-1 : Signalling flow notation 



B.3 Signalling flows demonstrating CSI session setup 
when no CS call has yet been set up 

B.3.1 Introduction 

This subclause provides signalling flows for CSI session setup, using session-based messaging as an example, 
established before any CS call has been established. 

The signalling flows are based on the session establishment flows in subclause A. 3 of 3GPP TS 24.247 [10], with some 
additions related to CSI. The UAC includes the feature tag "+g.3gpp.cs-voice" and "+g.3gpp.cs-video", in the Accept- 
Contact header. 

B.3. 2 Establishing a CSI session when no CS call has yet been 
set up 

Figure B.3. 2-1 shows the establishment of an MSRP session between two users as well. A CS call is then established 
after MSRP messages are communicated over the established PS connection. 
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CUA#1 



Intermediate IM CN subsystem 
entities 



Intermediate CS entities 



CUA#2 



1 . OPTIONS request and response 



-2. INVITE- 



-3. 100 Trying - 



4a. User-Agent P-CSCF#1 -> P-CSCF#2 
4b. INVITE request S-CSCF -> l-CSCF 



-5. INVITE- 



-6. 100. Trying - 



7, Reserve IP-CAN 
bearer for media 



8. Reiiabie exclnange of 9DP 



-10. 200OK- 



-11. ACK- 



12. Reserve IP-CAN 
bearer for media 



-9. 200OK- 



-13. ACK- 



1 4. Estabiishment of the MSRP session 



16. SETUP 



17. CALL PROCEEDING 



■ 15. Media exchange in PS domain 



18. SETUP 



19. CALL CONFIRM 



20. Early Assignment of User Plane Resources 



21. ALERTING 



22. Early Assignment of User Plane Resources 



23. ALERTING 



26. CONNECT 



27. CONNECT ACKNOWLEDGE 



28. Active Call in CS domain 



24. CONNECT 



25. CONNECT 
ACKNOWLEDGE 



Figure B.3.2-1 : Establishment of a session before a CS call is established 

The details of the signalhng flows are as follows: 
1 . UE capabilities exchange 
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Both UEs have performed a capability exchange. In the here shown example both UEs transfer their UE 
capability version and personal ME identifier as a part of the capability exchange. An example for capability 
exchange without the usage of UE capability version and personal ME identifier can be found in subclause 
B.6. 

2. INVITE request (CUA#1 to P-CSCF#1) - see example in table B.3.2-2 

The originating CUA wants to initiate a session with the terminating CUA. In this example, the originating 
CUA creates a local MSRP URL, which can be used for the communication between the two user agents. It 
builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP 
communication. 

The originating CUA declares its capabilities for CS-voice and CS-video, and requests to reach a UE with cs- 
voice or cs-video capabilities. The originating CUA includes its personal ME identifier and UE capability 
version in the User- Agent header. 

Table B.3.2-2: INVITE request (CUA#1 to P-CSCF#1) 



INVITE tel:+12125552222 SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Preferred-Identity: <tel:+12125551111> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+12125552222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip: [5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp>; +g. 3gpp. cs-voice; +g. 3gpp. cs-video 
Accept-Contact : *, +g . 3gpp . cs-voice, +g. 3gpp. cs-video; explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
User-Agent: PMI-0007, UCV-04 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=message 3402 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html image/ jpeg image/gif video/3gpp 

a=path:msrp:// [5555: : aaa: bbb: ccc : ddd] :3402/slll271;tcp 

a=max-size : 131072 



SDP The SDP contains a set of content types supported by CUA#1 and desired by the user at CUA#1 

for this session in the accept-types attribute and indicates the maximum size message that can be 
received by CUA#1 in the max-size attribute. 

3. 100 (Trying) response (P-CSCF#1 to CUA#1) 

The P-CSCF responds to the INVITE request with a 100 (Trying) provisional response as described in 
subclause A.3 of 3GPP TS 24.247 [10]. 

4a. User-Agent (P-CSCF#1 to P-CSCF#2) 

The User- Agent header field is transparently passed from P-CSCF#1 to P-CSCF#2. 
4b. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table B.3.2-4b 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2, after mapping the tel URI to a SIP -URL 
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Table B.3.2-4b: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -As sorted- Identity: 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Accept-Contact : 
Allow: 
User Agent : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



5. INVITE request (P-CSCF#2 to CUA#2) - see example in table B.3.2-5 

P-CSCF#2 forwards the INVITE request to the terminating CUA. 
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Table B.3.2-5: INVITE request (P-CSCF#2 to CUA#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Record-Route : <sip:pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 .net; lr>, 

<sip: scscfl . homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -Asserted- Identity : 
Privacy : 
From; 
To: 

Call-ID: 
Cseq: 
Contact : 
Accept-Contact : 
Allow: 
User-Agent : 
P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 
a= 



6. 100 (Trying) response (CUA#2 to P-CSCF#2) 

The terminating CUA sends a 100 (Trying) provisional response to P-CSCF#2 as described in subclause A. 3 
of3GPPTS 24.247 [10]. 

7. Reserve IP-CAN bearer for media 

The terminating CUA accepts the message session. The terminating CUA reserves an IP-CAN bearer for the 
message session media component. 

8. Reliable exchange of SDP 

SDP is conveyed between CUA#1 and CUA#2. The mechanism for this is not relevant for the example and is 
not described. 

9. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.3.2-9 

After reserving an IP-CAN bearer for the message session media component the terminating CUA sends a 
200 (OK) response for the INVITE request containing SDP that indicates that the terminating CUA has 
accepted the message session and listens on the MSRP TCP port returned in the path attribute in the answer 
for a TCP SETUP from the originating CUA. 

CUA#2 declares support only for CS-voice, not CS-video in its Contact header. The terminating CUA 
includes its personal ME identifier and UE capability version in the Server header. 
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Table B.3.2-9: 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .vis it edl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route ; <sip;pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>>, <sip; scscf2 . home 2 .net; lr>, 

<sip; scscfl . homel .net;lr>, <sip;pcscfl.visitedl.net;lr> 
Privacy; none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From; <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+12125552222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Contact: <sip: [5555: :eee:fff: aaa: bbb] : 8 805; comp=sigcomp>; +g. 3gpp. cs-voice 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Server: PMI-0EA2, UCV-OD 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp: // [5555: : eee : f f f : aaa:bbb] :3402/s234167;tcp 

a=max-size : 6553 6 



SDP The SDP contains the set of offered content types supported by CU A#2 and desired by the user at 

CUA#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be received by CUA#2 in the max-size attribute. 



10. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.3.2-10 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 
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Table B.3.2-10: 200 (OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net; lr>, 

<sip: scscfl . homel . net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 
P -Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
Server : 
Content-Type : 
Content-Length : 



P-Asserted-Identity: This header field is added by the intermediate IM CN subsystem entities in accordance with 

3GPPTS 24.229 [5]. 

1 1. ACK request (CUA#1 to P-CSCF#1) - see example in table B.3.2-11 

The CUA responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 

Table B.3.2-11: ACK request (CUA#1 to P-CSCF#1) 



ACK sip: [5555: :eee:fff :aaa:bbb] : 8805; comp=sigcomp SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip: scscfl . homel . net ; lr>, 

<sip: scscf2 . home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 
From: <sip : userl_publicl@homel .net>;tag=171828 
To: <sip:user2_publicl@home2 . net>; tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 



12. Reserve IP-CAN bearer for media 

The originating CUA reserves an IP -CAN bearer for the message session media component. 

13. ACK request (P-CSCF#2 to CUA#2) - see example in table B.3.2-13. 

P-CSCF#2 forwards the ACK request to the terminating CUA. 
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Table B.3.2-13: ACK request (P-CSCF#2 to CUA#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/2 . 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, 


SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 




s cscfl. home 1. net ;branch=z9hG4bK332b2 3.1, SIP/ 2. 0/UDP 




pcscf 1 .vis it edl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 




[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 




Max-Forwards: 66 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length : 





14. Establishment of the MSRP session 

The CUAs will establish the MSRP session as described in subclause A.3 of 3GPP TS 24.247 [10]. 

15. Media exchange in PS domain 

The CUAs will transfer media over the PS domain. 

16. Initiation of CS call estabUshment with SETUP from originating side (from CUA#1 to MSC#1) 

CUA#1 starts the CS call towards CUA#2 sending out the SETUP. 
Specifically for CSI, the SETUP message includes:- 

Called Party Number = [(Numbering plan identifier = ISDN/telephony numbering plan), 

(type of number = international number), (Number digits = 12125552222)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0007), (UE capability version = 
04)]. 

CUA#1 ensures that the Personal ME Identifier within the User-User IE of the SETUP correlates to the 
Personal ME Identifier used by CUA#1 in the preceding IM session. 

17. CALL PROCEEDING (MSC#1 to CUA#1) 

MSC#1 after call processing checks replies to CUA#1 with Call Proceeding. 
MSC#1 progresses the CS Call by contacting MSC#2. Intermediate CS entities could be involved. 
The User-User information provided by CUA#1 is forwarded by MSC#1 towards MSC#2. 
There is no specific CSI information in CALL_PROCEEDING. 

18. Initiation of CS terminating call with SETUP towards called party (from MSC#2 to CUA#2) 

MSC#2 starts the terminating call by initiating SETUP to CUA#2. 

Specifically for CSI, the SETUP message includes :- 

Called Party Number = [(type of number = international number ), 

(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 

Calling Party Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number ), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125551 1 1 1)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0007), (UE capability version = 
04)]. 

The Personal ME Identifier provided by CUA#1 is used by CUA#2 to relate to the appropriate remote 
terminal having the parallel IM session. The UE capability version provided by CUA#1 is used by CUA#2 to 
check whether the terminal capabilities of CUA#1 are already known by CUA#2. 

19. CALL CONFIRM indicating terminating CS Call is being processed (from CUA#2 to MSC#2) 

CUA#2 on accepting the terminating call for further processing respond to MSC#2 with CALL_CONFIRM. 
There is no specific CSI information in CALL_CONFIRM. 
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20. Allocation of user plane resources 

MSC#2 initiate provision of user plane resources. In this example call flow, this allocation takes place at this 
instance in time, but the network can opt to allocate resources after message 24 but certainly completes the 
allocation before message 25. 
There are no CSI specifics. 

21. ALERTING indicating end user is alerted, (from CUA#2 to MSC#2) 

When alerting towards the end user is started (ie. end user ringing) CUA#2 indicates that the call has been 

delivered by sending ALERTING to MSC#2. 

There are no CSI specifics in this message; in particular, User-User Information Element is not provided. 

22. Originating NW allocates user plane resources 

When MSC#2 receives ALERTING (see previous message 21), MSC#2 conveys this through Intermediate 

CS entities to MSC#1. Knowing that the call has delivered to far end user, MSC#1 initiates allocation of user 

plane resources to originating CUA#1. 

MSC#1 could have opt to allocate user plane resources to CUA#1 much earlier in the messaging sequence 

(eg. after CALL_PROCEEDING) or ]VISC#1 could allocate user plane resource much later eg. just before 

sending of message 26. 

This example flow chooses to indicate user plane resources being allocated at this point in time. 

23. ALERTING indicating far end alerting has started (from MSC#1 to CUA#1) 

MSC#1 sends to CUA#1 ALERTING indicating that the far end user is being alerted. This indication 
together with available user plane resource allow for ring tone to be provided to the originating user by the 
network. If the network had opted not to allocate user plane resources, then this ALERTING will allow the 
CUA#1 to generate local indications to the user that the call has been delivered to the far end user. 

24. CONNECT - far end user answers the call (from CUA#2 to MSC#2) 

When the user answers the call, CUA#2 sends CONNECT to MSC#2. 

Specifically for CSI, the CONNECT message includes:- 

User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0EA2), (UE capability version = 
OD)]. 

CUA#2 provides its Personal ME Identifier and UE capability version within the User-User IE. This Personal 
ME Identifier and UE capability version is the same as that provided by CUA#2 in 200 OK (message step 9) 
of the IM session. 

CUA#2 sending CONNECT starts connecting to the user plane resources. 

25. CONNECT ACKNOWLEDGE (from MSC#2 to CUA#2) 

Upon getting CONNECT, MSC#2 starts through connecting the call from the far end through the 
intermediate CS entities to MSC#L MSC#2 indicates this by sending CONNECT_ACKNOWLEDGE to 
CUA#2 and thus allowing CUA#2 to progress to active call state. 

MSC#2 conveys call acceptance to MSC#1 forwarding any User-User information to MSC#1 that is included 
in the CONNECT from CUA#2. 

26. CONNECT - far end has answered the call (from MSC#1 to CUA#1) 

MSC#1 indicates far end has answered the terminating call by sending CONNECT to CUA#L MSC#1 
having through connected the call on the network side now awaits CUA#1 to connect to the allocated user 
plane resources. 

Specifically for CSI, the CONNECT message includes: 

Connected Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 
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User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem registered), (Personal ME Identifier = 0EA2), (UE capability version = 
OD)]. 

The Personal ME Identifier provided by CUA#2 is used by CUA#1 to relate to the appropriate remote 
terminal having the parallel IM session. The UE capability version provided by CUA#2 is used by CUA#1 to 
check whether the terminal capabilities of CUA#2 are already known by CUA#1. 

27. CONNECT ACKNOWLEDGE (from CUA#1 to MSC#1) 

CUA#1 receiving CONNECT and with available user plane through connects the call and return 
CONNECT_ACKNOWLEDGE to MSC#1. The CONNECT ACKNOWLEDGE allows the network to 
progress to active call state. There are no CSI specifics in CONNECT ACKNOWLEDGE 

28. CS Call takes place 

The CS call takes place. 



B.4 Signalling flows demonstrating CSI session setup 
when a CS call is already established 

B.4.1 Introduction 

This subclause provides signalling flows for CSI session setup, using video session as an example of the IM session, 
established after any CS call has been established. 

The flows show some additions related to CSI. The CUA includes the feature tag '+g.3gpp.cs-voice' and '+g.3gpp.cs- 
video', in the Accept-Contact header and in the Contact header. The User Agent and Server Header carries the personal 
ME identifier. 

B.4. 2 Establishing a CSI session when CS call has been setup 

Figure B.4. 2-1 shows the establishment of video session between two users. A CS call is established before the video 
session is established. 

It is assumed that both the originating CUA and terminating CUA are using an IP-CAN with a separate bearer for SIP 
signalling which means that each CUA needs to provide resource reservation before starting the video session. 
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CUA#1 



c 



Intermediate IM CN subsystem 
entities 



Intermediate CS entities 



1. CS Call Setup 



2. OPTDNS request and response 



-3. INVITE- 



5. Reserve IP-CAN 
bearer for media 



-4. 100 Trying - 



6a. User-Agent P-CSCF#1 - P-CSCF#2 
6b. INVITE request S-CSCF -> l-CSCF 



-11. 183 OK- 



13. IP-CAN 

bearer for media 

is available 



-15. UPDATE- 



-18. 200 OK- 



-20. 200 OK- 



-21.ACK- 



-7. INVfTE- 



-8. 100. Trying- 



-10. 183 OK- 



12. PRACK -200(OK) exchange 



-16. UPDATE- 



-17. 200 OK- 



-19. 200 OK- 



-22. ACK- 



21. Establishment of the Video session 



CUA#2 



9. Reserve IP-CAN 
bearer for media 



14.IP-CAN bearer for 
media is available 



Figure B.4.2-1 : Establishment of a video session after a CS call is established 
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The details of the signalling flows are as follows: 

1. CScall 

A CS call setup is performed according to subclause B.5. 

2. UE capabilities exchange 

Both UEs have performed a capability exchange. In the here shown example both UEs transfer their UE 
capability version and personal ME identifier as a part of the capability exchange. An example for capability 
exchange without the usage of UE capability version and personal ME identifier can be found in subclause 
B.6. 

3. INVITE request (CUA#1 to P-CSCF#1) - see example in table B.4.2-2 

CUA#1 wants to initiate a session with the terminating CUA. In this example, the CUA#1 creates a video 
session as the IM session. CUA#1 includes the 'precondition" and lOOrel' options tag in the supported 
header. 

CUA#1 declares its capabilities for CS-voice and CS-video, and requests to reach a UE with CS-voice or CS- 
video capabilities by including these feature tags in the Accept-contact header and includes its personal ME 
identifier and UE capability version in User- Agent header. 

Table B.4.2-2: INVITE request (CUA#1 to P-CSCF#1) 



INVITE tel:+12125552222 SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Preferred-Identity: <tel:+12125551111> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+12125552222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: precondition, lOOrel 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip:[5555:: aaa: bbb: ccc : ddd] : 1357; comp=sigcomp>; +g. 3gpp. cs-voice; +g. 3gpp. cs-video 
Accept-Contact : *, +g. 3gpp. cs-voice, +g. 3gpp. cs-video; explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
User-Agent: PMI-0007, UCV-04 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=video 49232 RTP/AVP 107 

b=AS: 64. 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:107 H263/90000 

a=fmtp 107 profile=0 level=45 



SDP The SDP contains the video codec supported by CUA#1 and desired by the user at CUA#1 for this 

session. The precondition attributes are also included. 

4. 100 (Trying) response (P-CSCF#1 to CUA#1) 

The P-CSCF responds to the INVITE request with a 100 (Trying) provisional response as described in 
subclause A. 3 of 3GPP TS 24.247 [10]. 
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5. Reserve IP CAN bearer for media 

CUA#1 starts resource reservation based on the SDP. 
6a. User-Agent (P-CSCF#1 to P-CSCF#2) 

The User- Agent header field is transparently passed from P-CSCF#1 to P-CSCF#2. 

6b. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table B.4.2-3 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2, after replacing the tel URI with a SIP-URI in the 
Request URI. 

Table B.4.2-3: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK2 4 0f 34 .1, SIP/ 2 .0/UDP 
[ 5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards; 68 

Route : <sip;pcscfl .visitedl . net ; 7531; Ir; comp=sigcomp>, <sip;orig@scscfl. homel .net; lr> 

Record-Route ; <sip;scscfl. homel .net;lr>, <sip;pcscfl. visitedl. net; lr> 

P-Asserted- Identity: <tel:+12125551111> 

Privacy ; 

From; 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Accept-Contact : 

Allow: 

User-Agent : 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



7. INVITE request (P-CSCF#2 to CUA#2) - see example in table B.4.2-4 

P-CSCF#2 forwards the INVITE request to the terminating CUA. 
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Table B.4.2-4: INVITE request (P-CSCF#2 to CUA#2) 



INVITE sip: [5555: :eee:fff: aaa:bbb] : 8805; comp=sigcomp>; +g. 3gpp. cs- voice 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Record-Route : <sip:pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 . net ; lr>, 

<sip: scscfl . homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -As sorted- Identity : 
Privacy : 
From; 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Accept-Contact : 
Allow: 
User-Agent : 
P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



8 . 100 (Trying) response (CUA#2 to P-CSCF#2) 

The terminating CUA sends a 100 (Trying) provisional response to P-CSCF#2 as described in subclause A. 3 
of3GPPTS 24.247 [10]. 

9. Reserve IP-CAN bearer for media 

The terminating CUA sets up the bearer in accordance with the received SDP.. 

10. 183 (session progress) response (CUA#2 to P-CSCF#2) - see example in table B.4.2-5 

CUA#2 declares support for "CS-voice" and "CS-video" in its Contact header. The CUA includes the 
personal ME identifier and the UE capability version in the Server header. CUA#2 requires resource 
reservation and supports the precondition mechanism. 



£75/ 



3GPP TS 24.279 version 7.4.0 Release 7 



40 



ETSI TS 124 279 V7.4.0 (2007-03) 



Table B.4.2-5: 183 (session progress) response (CUA#2 to P-CSCF#2) 



SIP/2.0 183 Session progress 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route ; <sip;pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>>, <sip; scscf2 . home 2 .net; lr>, 

<sip; scscfl . homel .net;lr>, <sip;pcscfl. visitedl. net; lr> 
Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;+12125552222>;tag=31415 9 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 

Contact; <sip; [5555; ;eee;fff;aaa; bbb] ; 8 805; comp=sigcomp>; +g . 3gpp . cs-voice, +g . 3gpp . cs-video 
Allow; INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Require; lOOrel, precondition 
Server; PMI-0EA2, UCV-OD 
Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555;; eee ; f f f ; aaa ; bbb 

s=- 

c=IN IP6 5555; ;eee;fff ;aaa;bbb 

t = 

m=video 49234 RTP/AVP 107 

b=AS; 64.0 

a=curr;qos remote none 

a=curr;qos local none 

a=des;qos mandatory local sendrecv 

a=des;qos mandatory remote sendrecv 

a=conf;qos remote sendrecv 

a=inactive 

a=rtpmap;107 H263/90000 

a=fmtp 107 profile=0 level=45 



1 1 . 183 (session progress) response (P-CSCF#1 to CUA#1 ) - see example in table B.4.2-6 
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Table B.4.2-6: 183 (session progress) response (P-CSCF#1 to CUA#1 ) 



SIP/2.0 183 Session progress 

Via ; [5555; ;aaa; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route ; <sip;pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>, <sip; scscf2 . home 2 .net; lr>, 

<sip; scscfl . homel .net;lr>, <sip;pcscfl.visitedl.net;lr> 
Privacy ; 
From: 
To: 

Call-ID: 
Cseq: 
RSeq: 

P-Asserted-Identity : < user2_publicl@home2 . net>, < tel : +12125552222> 
Contact : 
Allow: 
Require : 
Server : 
Content-Type : 
Content-Length : 

v=0 

o=- 

s=- 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. PRACK-200 Exchange 

13. IP-CAN bearer available for media 

The IP-CAN bearer at CUA#1 is established. 

14. IP-CAN bearer available for media. 

The IP-CAN bearer at CUA#2 is established. 

15. UPDATE request (CUA#1 to P-CSCF#1 ) - see example in table B.4.2-7 

CUA#1 indicates that it can send and receive media. 
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Table B.4.2-7: UPDATE request (CUA#1 to P-CSCF#1 ) 



UPDATE <sip: [5555: : eee : f f f : aaa :bbb] : 8805; comp=sigcomp>; +g. 3gpp. cs-voice, +3gpp. cs-video 
Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc: ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 70 

Ir; comp=sigcomp>, 

tag=171828 



<sip:orig@scscfl. homel .net; lr> 



spi=87654321; portl=7531 



Route : <sip:pcscfl.visitedl.net:7531; 

From: <sip : userl_publicl@homel . net>; 

To: <tel:+12125552222> tag=314159 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 129 UPDATE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; 

Contact : <sip: [5555 : : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp>; +g. 3gpp. cs-voice; +g. 3gpp. cs-video 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=video 49232 RTP/AVP 107 

b=AS: 64.0 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=sendrecv 

a=rtpmap:107 H263/90000 

a=fmtp 107 profile=0 level=45 



16. UPDATE request (P-CSCF#2 to CUA#2 )- see example in table B.4.2-8 

The CUA#2 can start alerting. 



Table B.4.2-8: UPDATE request (P-CSCF#2 to CUA#2) 



UPDATE <sip: [5555: :eee:fff:aaa: bbb] : 8 805; comp=sigcomp>; +g . 3gpp . cs-voice, +g . 3gpp . cs-video 
Via: : SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branclrL=z91iG4bK361k21 . 1, 

SIP/2.0/UDP scscf2.1iome2.net;branclrL=z9hG4bK7 64z87. 1, S IP /2. 0/UDP 

icscf 2„s .liome2 . net ; brancli=z91iG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.liomel.net;brancli=z91iG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscf 1 . visitedl . net; brancli=z91iG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branc]i=z9]iG4bKnas]ids7 
Max-Forwards: 68 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Lengtli : 



17. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.4.2-9 

CUA 2 indicates that media can be received and sent. 
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Table B.4.2-9: 200(OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .vis it edl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp;branch=z9hG4bKnashds7 
From; <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+12125552222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 129 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t = 

m=video 49234 RTP/AVP 107 

b=AS: 64. 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=sendrecv 

a=rtpmap:107 H263/90000 

a=fmtp 107 profile=0 level=45 



18. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.4.2-10 

Table B.4.2-10: 200(OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: [5555: :aaa: bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v=0 



19. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.4.2-11 

CUA#2 accepts the session. 



£75/ 



3GPP TS 24.279 version 7.4.0 Release 7 44 ETSI TS 1 24 279 V7.4.0 (2007-03) 

Table B.4.2-11 : 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf 2„s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .vis it edl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Privacy; none 

From; <sip ; userl_publicl@homel . net>; tag=171828 
To; <tel;+12125552222>;tag=31415 9;tag=31415 9 
Call- ID; Cb03a0s0 9a2sdfglkj4 90333 
Cseq; 127 INVITE 

Contact; <sip; [5555; ;eee;fff;aaa; bbb] ; 8 805; comp=sigcomp>; +g . 3gpp . cs-voice, +g . 3gpp . cs-video 
Allow; INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Server; PMI-0EA2, UCV-OD 
Content-Length; 



20. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.4.2-12 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 

Table B.4.2-12: 200 (OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via; S IP /2. 0/UDP [5555; ; aaa; bbb; ccc; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 

P-Asserted- Identity; 

Privacy ; 

P-Asserted-ID; < user2_publicl@home2 . net>, < tel ; +12125552222> 

From; 

To; 

Call-ID; 

CSeq; 

Require ; 

Contact ; 

Allow; 

Server ; 

Content-Length ; 



21. ACK request (CUA#1 to P-CSCF#1) - see example in table B.4.2-13 

The CUA responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 

Table B.4.2-13: ACK request (CUA#1 to P-CSCF#1) 



ACK sip: <sip: [5555: :eee:fff: aaa : bbb] : 8 805; comp=sigcomp>; +g. 3gpp . cs-voice, +g . 3gpp . cs-video 

Via: SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Networ]c-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscfl. vis it edl . net : 7531; Ir; comp=sigcomp>, <sip: scscfl . liomel . net; lr>, 

<sip: scscf2 . ]iome2 . net; lr>, <sip:pcscf2. visited2 . net; lr> 
From: <sip : userl_publicl@]riomel . net>; tag=171828 
To: <sip:user2_publicl@]iome2 . net>; tag=314159 
Call- ID: Cb03a0s0 9a2sdfgl]cj4 90333 
Cseq: 127 ACK 
Content-Lengtli : 



22. ACK request (P-CSCF#2 to CUA#2) - see example in table B.3.2-14. 

P-CSCF#2 forwards the ACK request to the terminating CUA. 
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Table B.3.2-14: ACK request (P-CSCF#2 to CUA#2) 



ACK sip: 


<sip: [5555 


: : eee : f f f : aaa:bbb] 


:8805; 


comp=sigcomp>; +g 


. 3gpp 


cs- 


-voice. 


+g 


3gpp. cs 


-video 


Via: SIP/2. 0/UDP pcscf2.visited2.net: 


5088;c 


omp=sigcomp;bran 


ch=z9hG4bK361k21 


■ 1, 


SIP/2. 


0/UDP 


scscf2 


. home2 . net 


branch= 


=z9hG4bK764 


z87.1. 


SIP/2. 0/UDP 














scscfl 


. homel . net 
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Call-ID: 
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B.5 Signalling flows demonstrating capability information 
exchange in a CS call (only) 

B.5.1 Introduction 

This subclause provides signalling flows for exchange of information relevant for CSI in a CS call only. 

B.5.2 Establishing a CS call from a CSI capable UE 

Figure B.5.2- 1 shows the exchange of Radio Environment information, the IM Status, UE capability version and 
Personal ME Identifier by the CUAs of a CSI capable UE during a normal CS call establishment. 
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Figure B.5.2-1 : CS call establishment (example of late assignment of user plane resources) 

The details of the signalhng flows are as follows:- 

1 . Initiation of CS call establishment with SETUP from originating side (from CUA#1 to MSC#1) 

CUA#1 starts the CS call towards CUA#2 sending out the SETUP. 

Specifically for CSI, the SETUP message includes:- 

Called Party Number = [(Numbering plan identifier = ISDN/telephony numbering plan), 

(type of number = international number ), (Number digits = 12125552222)] 
User-User IE = [((Protocol ID =3GPP capability exchange protocol), (Radio Environment = 1), 
(IM Status = IM subsystem capable and willing to register to IM subsystem), 
(Personal ME Identifier = 0007), (UE capability version = 04)]. 

2. CALL PROCEEDING (MSC#1 to CUA#1) 

MSC#1 after call processing checks replies to CUA#1 with CALL_PROCEEDING. 

MSC#1 progress with the CS Call by contacting MSC#2. Intermediate CS entities could be involved. 

The User-User information provided by CUA#1 is forwarded by MSC#1 towards MSC#2. 

There is no specific CSI information in CALL_PROCEEDING. 
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3. Initiation of CS terminating call with SETUP towards called party (from MSC#2 to CUA#2) 

MSC#2 starts the terminating call by initiating SETUP to CUA#2. 

Specifcally for CSI, the SETUP message includes:- 

Called Party Number = [(type of number = international number ), 

(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 

Calling Party Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number ), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 121255511 1 1)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 

(IM Status = IM subsystem capable and willing to register to IM subsystem), 

(Personal ME Identifier = 0007), (UE capability version = 04)]. 

The Personal ME Identifier provided by CUA#1 is later used by CUA#2 to relate to a particular terminal of 
CUA#1 that initiated this CS call is later progressed to a CSI call. 

4. CALL CONFIRM indicating terminating CS Call is being processed (from CUA#2 to MSC#2) 

CUA#2 on accepting the terminating call for further processing respond to MSC#2 with CALL_CONFIRM. 
There is no specific CSI information in CALL_CONFIRM. 

5. ALERTING indicating end user is alerted, (from CUA#2 to MSC#2) 

CUA#2 indicates locally to the user that a call has arrived by starting local alerting. With the call delivered, 

CUA#2 sends ALERTING to MSC#2. 

There are no CSI specifics in this message; in particular, there is no inclusion of User-User Information 

Element. 

NOTE: This example flow has taken to illustrate local alerting by CUA#2. This is the case if in the SETUP 
MSC#2 allows this to be done, as MSC intends to do a late assignment of user plane resources. 

6. ALERTING indicating far end alerting has started (from MSC#1 to CUA#1) 

Through Internediate CS entities, MSC#2 informs MSC#1 that the call has been delivered. 

MSC#1 sends to CUA#1 ALERTING indicating that call has been delivered and far end user is being alerted. 

Only local indication of call delivery can be provided by CUA#1 to the user (ie. ringing tone) as user plane 

resources have yet to be assigned by MSC#1. 

There are no CSI specifics in this message. 

7. CONNECT - far end user answers the call (from CUA#2 to MSC#2) 

When the user answers the call, CUA#2 sends CONNECT to MSC#2. 

Specifically for CSI, the CONNECT message includes:- 

User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 
(IM Status = IM subsystem capable and willing to register to IM subsystem), 
(Personal ME Identifier = 0EA2), (UE capability version = OD)]. 

After sending the CONNECT, CUA#2 is ready to connect to user plane resources and does the instance user 

plane resources is allocated. 

MSC#2 conveys call answer to MSC#1 and forwards any User-User information to MSC#1 that is included 

in the CONNECT from CUA#2. 

The provision of the Personal ME Identifier is to allow CUA#2 and CUA#1 to bind this CS Call answered by 

a particular terminal of CUA#2 to any eventual associated IM session to progress this CS call to a CSI call. 

8. Allocation of user plane resources 

MSC#2 has to allocate user plane resources to CUA#2 to allow speech to take place. In this example, this is 
the very latest point in time that MSC#2 can allocate such resources. This is referred to as Late Assignment. 
With the completion of the user plane resources, CUA#2 connects up and speech begins. 
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9. CONNECT ACKNOWLEDGE (from MSC#2 to CUA#2) 

Upon completing Late Assignment, MSC#2 starts through connecting the call all the way from CUA#2 to the 
far end through the Intermediate CS Entities to MSC#L 

MSC#2 indicates this by sending CONNECT_ACKNOWLEDGE to CUA#2 and thus allowing CUA#2 to 
progress to active call state. 

10. Originating NW allocates user plane resources 

Knowing that the call has been answered, MSC#1 initiates allocation of user plane resources to originating 

CUA#1. 

In this example, this is the latest point in time that MSC#1 can assign the user plane resources for speech to 

take place. 

1 1 . CONNECT (from MSC#1 to CUA#1) 

MSC#1 indicates far end has answered the terminating call by sending CONNECT to CUA#1. MSC#1 

through connects the call on the network side and awaits CUA#1 to connect to the allocated user plane 

resources. 

Specifically for CSI, the CONNECT message includes: 

Connected Number = [(presentation indicator = Presentation allowed), 

(screening indicator = Network provided), (type of number = international number), 
(Numbering plan identifier = ISDN/telephony numbering plan), (Number digits = 12125552222)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 
(IM Status = IM subsystem capable and willing to register to IM subsystem), 
(Personal ME Identifier = 0EA2), (UE capability version = OD)]. 

12. CONNECT ACKNOWLEDGE (from CUA#1 to MSC#1) 

CUA#1 receiving CONNECT and with available user plane through connects the call and return 
CONNECT_ACKNOWLEDGE to MSC#1. The CONNECT ACKNOWLEDGE is to allow the network to 
progress to active call state. The CONNECT ACKNOWLEDGE does not have any CSI specifics. 

13. CS Call takes place 

The CS call takes place. 



B.6 Signalling flows demonstrating UE capability 
exchange with no UE capability version 

B.6.1 Introduction 

This subclause provides signalling flows for UE capability exchange with no UE capability version and no personal ME 
identifier outside a CS call or when a CS call is already in progress. 

B.6. 2 UE capability exchange outside a CS call 

Figure B. 6.2-1 shows the UE capability exchange using the OPTIONS method. 
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Figure B.6.2-1 : UE capability exchiange before any CS call is established 
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The details of the signalling flows are as follows: 

1. OPTIONS request (CUA#1 to P-CSCF#1) - see example in table B.6.2-1 

The originating CUA wants to know the capabilities of the terminating UE, preferably a UE that supports 
CS -voice and CS -video, or one or the other. 

Table B.6.2-1 : OPTIONS request (CUA#1 to P-CSCF#1) 



OPTIONS tel:+12125552222 SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-P refer red- Identity: <tel:+l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+12125552222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 OPTIONS 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Accept -Contact : *, +g. 3gpp. cs-voice, +g. 3gpp. cs-video; explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Accept: application/sdp 
Content-Length: 



2. OPTIONS request (S-CSCF#1 to I-CSCF#2) - see example in table B.6.2-2 

S-CSCF#1 forwards the OPTIONS request to the I-CSCF#2, after mapping the tel URI to a SIP-URI. 

Table B.6.2-2: OPTIONS request (S-CSCF#1 to l-CSCF#2) 



OPTIONS sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscfl .homel .net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscfl. visitedl. net ;branch=z9hG4bK24 Of 34. 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P-Asserted- Identity: 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 

Accept-Contact : 
Allow: 
Accept : 
Content-Length: 



3. Routing decision based on caller preferences and callee capabilities 

The S-CSCF for CUA#2 uses caller preferences (information from the Accept-Contact header) and callee 
capabilities (information stored in the Registrar from the REGISTER Contact header) information to decide 
how to route the OPTIONS request. 

4. OPTIONS request (P-CSCF#2 to CUA#2) - see example in table B.6.2-4 

P-CSCF#2 forwards the OPTIONS request to the terminating CUA. 



£75/ 



3GPP TS 24.279 version 7.4.0 Release 7 51 ETSI TS 1 24 279 V7.4.0 (2007-03) 

Table B.6.2-4: OPTIONS request (P-CSCF#2 to CUA#2) 



OPTIONS sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/2 . 0/UDP pcscf2 . visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, 


SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 




icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 




scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 




pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 




Max-Forwards: 65 




Record-Route : <sip:pcscf 2 . visited2 . net : 5088; Ir; comp=sigcomp>, <sip:scscf2 .home 


2.net;lr>, 


<sip:scscfl .homel . net; lr>, <sip:pcscfl. visitedl. net; lr> 




P -Asserted- Identity: 




Privacy : 




From: 




To: 




Call-ID: 




Cseq: 




Accept-Contact : 




Allow: 




Accept : 




Content-Length: 




P-Called-Party-ID : 





5. Save CUA#l"s address, prepare 200 OK response 

The terminating CUA caches any address related information it learns about CUA#1 from the OPTIONS 
request, such as its SIP URI. The terminating CUA adds feature parameters to the Contact header field in the 
OPTIONS response indicating its capabilities. The feature parameters that were included in the registration 
generated by the terminating CUA are used in the OPTIONS response. 

6. 200 (OK) response (CUA#2 to P-CSCF#2) - see example in table B.6.2-6 

The terminating CUA sends a 200 (OK) response for the OPTIONS request containing the terminating 
CUA"s capabilities. This information is declared both in the feature tags listed in the Contact header and in 
the SDP. In this example, CUA#2 declares capability for cs-voice, but not cs-video, and it declares support 
for MSRP, RTP video (H.263) and RTP audio (AMR). 
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Table B.6.2-6: 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .vis it edl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route ; <sip;pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>>, <sip; scscf2 . home 2 .net; lr>, 

<sip; scscfl . homel .net;lr>, <sip;pcscfl.visitedl.net;lr> 
Privacy; none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=123451D0FCEll 
From; <sip : userl_publicl@homel . net>; tag=171828 
To: <sip:user2_publicl@home2 . net>; tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 OPTIONS 

Contact: <sip:user2_publicl@home2 . net >; +g. 3gpp. cs-voice, <tel : +12125552222> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=0 

m=message TCP/MSRP * 

a=accept-types : text /plain text/html message/cpim image/ jpeg image/gif video/3gpp 

a=max- s ize: 65536 

m=video RTP/AVP 96 

a=rtpmap:96 H263-2000/90000 

m=audio RTP/AVP 97 

a=rtpmap:97 AMR/8000 



SDP The SDP contains: 

The set of offered content types supported by UE#2 and desired by the user at UE#2 for an MSRP 
session in the accept-types attribute and indicates the maximum size message that can be received by 
UE#2 in the max-size attribute (no dynamically allocated attributes are included, for example, the a=path 
line is not there); 

The supported video codec and relevant parameters (but no dynamically allocated parameters); 

The supported audio codec and relevant parameters (but no dynamically allocated parameters). 

No ports are declared since UE capabilities are just being listed. 



7. 200 (OK) response (P-CSCF#1 to CUA#1) - see example in table B.6.2-7 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 
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Table B.6.2-7: 200 (OK) response (P-CSCF#1 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net; lr>, 

<sip: scscfl . homel . net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 
P -Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



8. Cache information on CUA#2"s capabilities 

Since no CS call is ongoing, cache the information obtained on CUA#2"s capabilities for later use within a CS 
call. 

9. OPTIONS request (CUA#2 to P-CSCF#2) - see example in table B.6.2-9 

The originating CUA wants to know the capabilities of the terminating UE, preferably a UE that supports cs- 
voice and cs-video, or one or the other. 

Table B.6.2-9: OPTIONS request (CUA#2 to P-CSCF#2) 



OPTIONS tel:+12125551111 SIP/2.0 

Via: SIP/2.0/UDP [5555: : eee : f f f : aaa : bbb] : 8 805; comp=sigcomp; branch=af 45K32 9 jstd43 

Max-Forwards: 70 

Route : <sip:pcscf2 .visited2 . net : 7743; Ir; comp=sigcomp>, <sip:orig@scscf2. home 2 .net; lr> 

P-P refer red- Identity: <tel:+l-212-555-2222> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=123451D0FCEll 

Privacy: none 

From: <sip : user2_public2@home2 . net>; tag=1912031 

To: <tel:+12125552222> 

Call- ID: ast324c2ho9512go923 8ks4b 

Cseq: 127 OPTIONS 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=23456789; spi-s=12345678; 

port-c=8318; port-s=7743 
Accept -Contact : *, +g. 3gpp. cs-voice, +g. 3gpp. cs-video; explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Accept: application/sdp 
Content-Length: 



10. OPTIONS request (S-CSCF#1 to I-CSCF#2) - see example in table B.6.2-10 

S-CSCF#1 forwards the OPTIONS request to the I-CSCF#2, after mapping the tel URI to a SIP-URL 
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Table B.6.2-10: OPTIONS request (S-CSCF#2 to l-CSCF#1) 



OPTIONS sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch= af 45K329 jsg213, SIP/2. 0/UDP 
pcscf2.visited2.net;branch= af 45K329 jsbbb2, SIP/2. 0/UDP 
[5555: : eee : f f f : aaa:bbb] : 8805; comp=sigcomp; branch= af 45K329 jstd43 

Max-Forwards: 68 

Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 

P -As sorted- Identity: 

P-Charging-Vector : icid-value="H7a2rvdguTd6eYt7br=ac?+g54 68HdrdRf 54b" ; orig-ioi=home2 .net 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Accept-Contact : 

Allow: 

Accept : 

Content-Length: 



1 1 . Routing decision based on caller preferences and callee capabilities 

The S-CSCF for CUA#2 uses caller preferences (information from the Accept-Contact header) and callee 
capabilities (information stored in the Registrar from the REGISTER Contact header) information to decide how 
to route the OPTIONS request. 

12. OPTIONS request (P-CSCF#1 to CUA#1) - see example in table B.6.2-12 

P-CSCF#2 forwards the OPTIONS request to the terminating CUA. 

Table B.6.2-12: OPTIONS request (P-CSCF#1 to CUA#1) 



OPTIONS sip: [5555: :aaa:bbb:ccc:ddd] :1357;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net : 6809; comp=sigcomp;branch= af 45K329 jsgf f f , SIP/2. 0/UDP 

scscfl.homel.net;branch= af 45K329 jsl234, SIP/2. 0/UDP icscf l„s . homel . net ; branch= 

af45K329jsskit, SIP/2. 0/UDP scscf 2 . home2 . net ; branch= af 45K329 jsg213, SIP/2. 0/UDP 

pcscf2.visited2.net;branch= af 45K329 jsbbb2, SIP/2. 0/UDP 

[5555: :eee:fff: aaa:bbb] : 8805; comp=sigcomp; branch= af45K329jstd4 3 
Max-Forwards : 65 
Record-Route : <sip:pcscfl .visitedl . net : 6809; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr>, 

<sip: scscf2 . home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 
P -As sorted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 

Accept-Contact : 
Allow: 
Accept : 

Content-Length: 
P-Called-Party-ID : 



13. Save CUA#l"s address, prepare 200 OK response 

The terminating CUA caches any address related information it learns about CUA#1 from the OPTIONS 
request, such as its SIP URL The terminating CUA adds feature parameters to the Contact header field in the 
OPTIONS response indicating its capabilities. The feature parameters that were included in the registration 
generated by the terminating CUA are used in the OPTIONS response. 

14. 200 (OK) response (CUA#1 to P-CSCF#1) - see example in table B.6.2-14 

The originating CUA sends a 200 (OK) response for the OPTIONS request containing the originating CUA"s 
capabilities. This information is declared both in the feature tags listed in the Contact header and in the SDP. In 
this example, CUA#2 declares capability for cs-voice, but not cs-video, and it declares support for MSRP, RTP 
video (H.263) and RTP audio (AMR). 
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Table B.6.2-14: 200 (OK) response (CUA#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl .visitedl . net : 6809; comp=sigcomp; branch= af 45K329 jsgf f f , SIP/2. 0/UDP 

scscfl.homel.net;branch= af 45K329 jsl234, SIP/2. 0/UDP icscf l_s . homel . net ; branch= 

af45K329jsskit, SIP/2. 0/UDP scscf 2 . home2 . net ; branch= af 45K329 jsg213, SIP/2. 0/UDP 

pcscf2.visited2.net;branch= af 45K329 jsbbb2, SIP/2. 0/UDP 

[5555: :eee:fff: aaa:bbb] : 8 805; comp=sigcomp; branch= af45K329jstd4 3 
Record-Route : <sip:pcscfl .visitedl . net : 6809; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr>, 

<sip: scscf2 . home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 
Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip : userl_publicl@homel . net>; tag=171828 
To : <sip : user2_publicl@home2 .net>;tag=31415 9 
Call- ID: ast324c2ho9512go923 8ks4b 
Cseq: 127 OPTIONS 
Contact: <sip:userl_publicl@homel . net >; +g. 3gpp. cs-voice; +g. 3gpp. cs-video, 

<tel:+12125551111> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t = 

m=message TCP/MSRP * 

a=accept-types : text /plain text/html message/cpim image/ jpeg image/gif video/3gpp 

a=max- s ize: 65536 

m=video RTP/AVP 96 

a=rtpmap:96 H263-2000/90000 

m=audio RTP/AVP 97 

a=rtpmap:97 AMR/8000 



SDP The SDP contains: 

The set of offered content types supported by UE#2 and desired by the user at UE#2 for an MSRP 
session in the accept-types attribute and indicates the maximum size message that can be received by 
UE#2 in the max-size attribute (no dynamically allocated attributes are included, for example, the a=path 
line is not there); 

The supported video codec and relevant parameters (but no dynamically allocated parameters); 

The supported audio codec and relevant parameters (but no dynamically allocated parameters). 

No ports are declared since UE capabilities are just being listed. 



15.200 (OK) response (P-CSCF#2 to CUA#2) - see example in table B.6.2-15 

P-CSCF#1 forwards the 200 (OK) response to the originating CUA. 
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Table B.6.2-15: 200 (OK) response (P-CSCF#2 to CUA#2) 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP [5555: : eee : f f f : aaa:bbb] : 8 805; comp=sigcomp; branch=af 45K32 9 jstd43 

Record-Route : <sip:pcscfl .visitedl . net : 6809; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr>, 

<sip: scscf2 . home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 
P -Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 

m= 
a= 

m= 
a= 



16. Cache information on CUA#l"s capabilities 

Since no CS call is ongoing, cache the information obtained on CUA#l"s capabilities for later use within a CS call. 

17. CS call establishment 

Either UE initiates the setup of a CS call between CUA#1 and CUA#2, as described in subclause B.5. However, in 
subclause B.5 UE capability version and personal ME identifier are used. 

B.6.3 UE capability exchange when a CS call is already in 
progress 

Figure B.6.3-1 shows the UE capability exchange using OPTIONS when a CS call is already in progress between 
CUA#1 and CUA#2. 
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Figure B.6.3-1 : UE capability exchange using OPTIONS after a CS call is established 
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Only the details of the signalling flows are described that are different from the flows where UE capability exchange 
happens before a CS call is established (see subclause B.6.2). 

1 . CS call establishment 

Either UE initiates the setup of a CS call between CUA#1 and CUA#2, as described in subclause B.5. In this 
example the UE capability version and personal ME identifier are not transferred as part of the CS call 
signalling. Therefore, CUA#1 is not aware of the capabilities of CUA#2 and starts a capability exchange. 

2. OPTIONS request (CUA#1 to P-CSCF#1) 

As the CS call is already established, the OPTIONS request is built using the tel URI that is the same as the 
connected number received in the Connect Message from the already established CS call. This assumes that 
CUA#1 originated the CS call. 

2. to 5. OPTIONS request (CUA#1 to CUA#2) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 1 to 4. 

6. Cache information of CUA#l"s capabilities and display capabiUties available during this CS call 

Since a CS call is ongoing, use the information in the OPTIONS request to indicate to the user which capabilities 
are available during this CS call. Also, cache the information about CUA#l"s capabilities for later use. 

7. to 8. 200 (OK) response to OPTIONS request (CUA#2 to CUA#1) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 6 to 7. 

9. Cache information of UE#2"s capabilities and display capabilities available during this CS call 

Since a CS call is ongoing, use the information in the 200 (OK) response to the OPTIONS request to indicate to 
the user which capabilities are available during this CS call. Also, cache the information about UE#2"s 
capabilities for later use. 

10. OPTIONS request (CUA#2 to P-CSCF#2) 

When the CS call is already established, then the OPTIONS request is built using the tel URI that is the same as 
the calling number received in the SETUP Message from the already established CS call. 

10. to 13. OPTIONS request (CUA#2 to CUA#1) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 9 to 12. 

14. Cache information of CUA#2"s capabiUties and display capabilities available during this CS call 

Since a CS call is ongoing, use the information in the OPTIONS request and if available previously stored 
capabilities of CUA#2 to indicate to the user which capabilities are available during this CS call. Also, cache the 
information about CUA#2"s capabilities for later use. 

15. to 16. 200 (OK) response to OPTIONS request (CUA#1 to CUA#2) 

Same as steps for OPTIONS when no CS call is established, see subclause B.6.2 steps 14. to 15. 

17. Cache information on UE#l"s capabiUties and display capabiUties available during this CS caU 

Since a CS call is ongoing, use the information in the 200 (OK) response to the OPTIONS request to indicate to the user 
which capabilities are available during this CS call. Also, cache the information obtained on UE#l"s capabilities for 
later use. 
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B.7 Signalling flows demonstrating UE capability 
exchange with UE capability version 

B.7.1 Introduction 

This subclause provides signalling flows for UE capability exchange with UE capability version and personal ME 
identifier outside a CS call or when a CS call is already in progress. 

B.7. 2 UE capability exchange with UE capability version 

Figure B.7. 2-1 shows the UE capability exchange using OPTIONS when an IM session or a CS call is already in 
progress between CUA#1 and CUA#2. In this figure, CUA#2 received UE capability version and personal ME 
identifier, which means for instance that CUA#l"s capabilities have been significantly updated. 

The difference between with no UE capability version (Figure B. 6.2-1, B.6.3-1) and with UE capability version (Figure 
B.7. 2-1) of UE capability exchange is that the frequency of OPTIONS transaction is reduced through exchange of UE 
capability version (Figure B.7. 2-1). 
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Figure B.7.2-1 : UE capability exchange using OPTIONS after receiving UE capability version during 

an IM session setup or a CS call setup 

If UE capability exchange performs after receiving UE capability version and personal ME identifier during an IM 
session setup, initial IM session setup messages are used as follows; 

1. INVITE request and 200 OK response 

la. INVITE request (CUA#1 to CUA#2) - see example in table B.7.2-la 

CUA#1 sends INVITE request with UE#l"s capability version to CUA#2. The UE#l"s capability version is set to 
a different value from the previously stored UE#l"s capability version, because the CUA#1 has updated its 
capability. 

Table B.7.2-1 a: INVITE request (CUA#1 to CUA#2) 
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INVITE tel:+12125552222 SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Preferred-Identity: <tel:+l-212-555-llll> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <tel:+12125552222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 OPTIONS 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip: [5555 : : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp> 
Accept -Contact : *, +g. 3gpp. cs-voice, +g. 3gpp. cs -video; explicit 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Accept: application/sdp 
User-Agent: PMI-0007, UCV-04 
Content-Length: (..) 



lb. 200 OK response (CUA#2 to CUA#1) - see example in table B.7.2-lb 
CUA#2 accepts the session 

Table B.7.2-1b: 200 OK response (CUA#2 to CUA#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 
To: <tel:+12125552222>;tag=31415 9;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Contact: <sip: [5555: : eee : f f f : aaa:bbb] : 8805; comp=sigcomp>; +g. 3gpp. cs-voice, +g. 3gpp. cs-video 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Server: PMI-0EA2, UCV-OD 
Content-Length: (...) 



If UE capability exchange performs after receiving UE capabiHty version during a CS call setup, initial CS call setup 
messages are used as follows; 

1'. SETUP request and CONNECT response 
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I'a. SETUP request (CUA#1 to CUA#2) 

CUA#1 send CS call SETUP message to CUA#2. The UE#l"s capability version is set to a different value from 
the previously stored UE#l"s capability version, because the CUA#1 has updated its capability. Specifically for 
CSI with UE capability version, the SETUP message includes; 

- Called Party Number = [(Numbering plan identifier = ISDN/telephony numbering plan), 

(type of number = international number), (Number digits = 12125552222)] 
User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), 
(Personal ME Identifier = 0007), (UE Capability Version = 04)]. 

CUA#1 ensures that the Personal ME Identifier and UE capability version within the User-User IE of the SETUP 
correlates to the Personal ME Identifier and UE capability version used by CUA#1 in the preceding IM session. 

I'b. CONNECT response (CUA#2 to CUA#1) 

CUA#2 send CS call CONNECT message to CUA#1 to estabhsh CS bearer. Specifically for CSI with UE 
capability version, the CONNECT message includes; 

- User-User IE = [(Protocol ID =3GPP capability exchange protocol), (Radio Environment =1), (Personal ME 
Identifier = 0EA2), (UE Capability Version = OD)]. 

CUA#2 uses the Personal ME Identifier and UE capability version provided by CUA#1 in SETUP to bind the 
IM session to this CS Call. CUA#2 returns the Personal ME Identifier and UE capability version provided by 
CUA#2 within the User-User IE. 

2. CUA#2 decide whether to send OPTIONS request according to UE#l"s capability version 

CUA#2 decides whether to send SIP OPTIONS request to CUA#1 according to UE capability version received 
during the IM session setup. If the received UE capability version is set differently from previously stored UE 
capability version, it means that CUA#1 has updated its capabilities. In this case, CUA#2 sends SIP OPTIONS 
request to CUA#1 to get CUA#l"s updated capability information. 

3 to 6. OPTIONS request (CUA#2 to CUA#1) 

Same as steps for OPTIONS when IM session is established, see subclause B.6.2 steps 9. to 12. 

7. Store CUA#2"s address information and display capabiUties, which have been updated available during this 
IM session 

Since an IM session is ongoing, use the information in the SIP OPTIONS request to indicate to the user which 
capabilities are available during this IM session. Also, store the address information and capabilities from 
CUA#2 for later use. 

8. to 10. 200 (OK) response to OPTIONS request (CUA#1 to CUA#2) 

Same as steps for OPTIONS when IM session with no UE capability version is established, see subclause B.6.2 
steps 14. to 15. 

11. Store information on CUA#l"s capabiUties 

Since an IM session is ongoing, use the information in the 200 (OK) response to the OPTIONS request to 
indicate to the user which capabilities are available during this IM session. Also, store the capability information 
from CUA#1 for later use. 
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B.8 Signalling flows demonstrating an IMS multimedia 
session setup with IMS origination and CSI 
termination. 

B.8.1 Introduction 

This subclause provides signalling flows for establishing an IM multimedia session with IMS origination and CSI 
termination. 

The flows shows some additions related to CSI. The B2B CUA of the CSI AS includes the feature tag '+g.3gpp.cs- 
voice' and '+g.3gpp.cs-video', in the Accept-Contact header and in the Contact header. Additionally the Radio 
Enviroment Capability, the IM Status, the Personal ME Identifier and the UE capability version are provided by the 
B2BCUAoftheCSIAS. 

UE#1 illustrated in the figures is a UE that originates multimedia sessions without involving the CS domain for media 
transport. 

B.8. 2 CSI interworking function establishing a combinational CS 
call and an IMS session to a terminating UE 

Figure B. 8.2-1 illustrates an example signalling flow for an IMS originated multimedia session (with real time voice 
component and a non-real time messaging component) a CSI UE interworked by the CSI interworking function in the 
IM CN subsystem. 

In this example the messaging component is transported by MSRP. 

In this example, UE#1 needs to reserve local resources. 

In this example, the "100 Trying" in response to an initial INVITE and other SIP message exchanges, eg. the 183 
Session Progress from CUA#2 and PRACK going to CUA#2, are not shown for simplicity. 

In this example, the originating NW and the terminating NW are shown as two separate NWs. This does not imply that 
the originating and terminating cannot be just one NW. What this example is meant to illustrate is which part of the NW 
(originating or terminating) that the CSI AS for terminating session handling is invoked. 

In this example the CSI AS in its 183 Session Progress to UE#1 provides an SDP answer wherein the audio component 
indicates a "c=" line destination pointing to the MGW and for the MSRP component the "c=" line at session level 
indicates the destination as the terminating CUA itself. 



£75/ 



3GPP TS 24.279 version 7.4.0 Release 7 



64 



ETSI TS 124 279 V7.4.0 (2007-03) 



In originating NW 


In terminating NW 


r 
































1 




UE#1 




Intermediate IM CN 
subsystem #1 entities 




Intermediate IM CN 
subsystem #2 entities 




CSI AS 




MGCP 




MOW 




VMSC 




CUA#2 








1. 


INVITE 


2 INVITE 






































12a 


183 Session Progress 


















" 








2a. IPC evaluation 








3. INVITE 












4. Termination 
logic is applied 




5. INVITE (SIP URI) 






5a. INVITE (SIP URI) 




7. INVITE (Tel URI) 




8. lAM 














6. Reserve 
IP-CAN 
bearer 

for media 






( 


7a. INVITE (Tel URI) 




10. 200 OK (SIP URI) 


9. H. 






i/IGW 


HQ interaction with tlie^ 










10a. 200 OK (SIP URI) 












^ 11.ACK 


11a. ACK 


^ 1 2. 1 83 V 


Session Progress 








12a. 183 Sessior 




12. 183 Session Progre 


ss 
jress 


Proaress 


12a. 183 Session Pro 




13a. PRACK ^ 


13. PRACK 


13a. PRACK ^ 




^ 1 7a. 200 OK 










^ 15. PRACK 




1 4. Reserve 

IP-CAN 

bearer for 

media 




15a. PRACK 




16. 200 OK 


16a. 200 OK ^ 




^ 17. 200 OK 












1 7a. 200 OK 



















































Figure B/8.2-1 : Interworking an originating multimedia IIVIS session to a CSI UE 
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Figure B/8.2-1 (continued): Interworking an originating multimedia IIVIS session to a OS! UE 
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1. SIP INVITE request (from originating UE#1) 

UE#1 wants to initiate a multimedia session with the terminating CUA#2 and sends out an INVITE request. 
See example in Table B.8.2-1. 



Table B.8.2-1: INVITE request (UE#1 to P-CSCF#1) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip:pcscfl. homel .net:7531;lr; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Pref erred-Identity : "Joe Bloke" <sip:user3_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <tel: +l-212-555-3333>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

Contact: < sip: [5555 :: aaa:bbb: ccc : ddd] : 1357; comp=sigcomp > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 

m=message 3402 TCP/MSRP 

a=accept-types :message/cpim text/plain text/html image/ jpeg image/gif video/3gpp 

a=path:msrp: // [5555: : aaa: bbb: ccc : ddd] :3402/slll271;tcp 

a=max-size : 131072 



2. SIP INVITE request (from originating intermediate IM CN subsystem #1 to the terminating IM CN 
subsystem #2) 

The originating IM CN #1 maps the Tel URI to a SIP URI and forwards the INVITE request towards the 
terminating IM CN #2. See example in Table B.8.2.-2 
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Table B.8.2-2: INVITE request (S-CSCF#1 to S-CSCF#2) 



INVITE <sip:user2_public2@home2.net> SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscfl.homel.net;branch=z9hG4bK240f34. 1, SIP/2. 0/UDP 
[5555 ; ; aaa ; bbb ; ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip : as . homel . net; lr>, <sip : cb03a0s0 9a2sdfglkj4 90333@scscfl . homel .net; lr> 

Record-Route: <sip: scscf 1 .homel . net>, <sip:pcscfl .homel . net> 

P-Asserted-Identity : "Joe Bloke" <sip : user3_publicl@homel . net>, <tel: +l-212-555-333> 

P-Access-Network-Inf o : 

Privacy: none 

P-Charging-Vector : 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22] 

ecf=[5555: : If f : 2ee : 3dd: 4ee] ; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

From: 

To: 

Call-ID: 

Cseq: 127 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v=0 



2a. Evaluation of initial filter criteria (at S-CSCF#2) 

The S-CSCF#2 performs iFC evalutation in order to decide what services to invoke and how to route the 
INVITE request. In this example, the S-CSCF#2 determines that the INVITE request must be routed to the CSI 
AS. 

3. SIP INVITE request (to the target CSI application server) 

S-CSCF#2 routes the INVITE to the indicated CSI application server. See example in Table B.8.2-3. 
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Table B.8.2-3 INVITE request (S-CSCF#2 to CSI application server) 



INVITE <sip:user2_public2@home2.net> SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=y2y2y2y2y2y2y2 . 2, 
SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23. 1, 
SIP/2. 0/UDP pcscfl.homel.net;branch=z9hG4bK240f34. 1, SIP/ 2. 0/UDP 
[5555 ; ; aaa : bbb ; ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards; 66 

Route : <sip ; as . homel . net; lr>, <sip : cb03a0s0 9a2sdfglkj4 90333@scscfl . homel .net; lr> 

Record-Route ; <sip;scscf2. home 2 . net>, 
<sip:scscfl. homel . net>, 
<sip:pcscfl . homel . net> 

P-Asserted-Identity : "Joe Bloke" <sip ; user3„publicl@homel . net> 

P-Access-Network-Inf o : 

Privacy: none 

P-Charging-Vector : 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22] 

ecf=[5555: : If f : 2ee : 3dd: 4ee] ; ecf=[5555: : 6aa: 7bb: 8cc : 9dd] 

From: 

To: 

Call-ID: 

Cseq: 127 

Supported: 

Contact : 

Allow: 

Content-Type : 

Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



4. Termination logic processing by the CSI AS 

The CSI application server invokes its termination logic and based on the requested media components it decides 
to do a session split, i.e. to terminate the voice component via the CS domain and the session containing MSRP 
stream via an IP-CAN. 

NOTE 1 : For splitting the session into two parts, the CSI AS will later initiate two INVITE requests: one in step 5 
for the MSRP component and another in step 7 for the voice component. The sequence of these INVITE 
requests is implementation specific (although this example shows first the INVITE for the voice 
component). 

NOTE 2: The two sessions (for the voice and session containing MSRP stream) are presented to the user as a single 
composite session. 



5. SIP INVITE request (from CSI AS to terminating user CUA#2 in the IMS domain) 

The CSI AS (acting as a B2B UA) initiates an INVITE request for the session containing the MRSP stream to 
the terminating CUA#2 with the Request URI set to the SIP URI received in the initial INVITE request received 
at step 3. See example in Table B. 8.2-4 
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Table B.8.2-4: INVITE request (CSI AS as B2BUA to S-CSCF#2 for IMS session) 



INVITE sip: user2_public2@home2.net SIP/2.0 

Via: SIP/2. 0/UDP as.home2.net 

Max-Forwards: 70 

Route : 

Record-Route : <sip : as . home 2 .net; lr> 

P-Asserted-Identity: <tel: +l-212-555-3333> 

P-Access-Network-Inf o : 

P-Charging-Vector : 

Privacy: none 

Supported: precondition 

From: <tel: +l-212-555-3333>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Contact: <sip: [5555: :aaa: bbb : ccc : ddd] : 1357; comp=sigcomp> 

Accept-Contact : *, +g. 3gpp. cs-voice, +g. 3gpp. cs-video; explicit 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t = 

m=message 3402 TCP/MSRP 

a=accept-types :message/cpim text/plain text/html image/ jpeg image/gif video/3gpp 

a=path:msrp: // [5555: : aaa: bbb: ccc : ddd] :3402/slll271;tcp 

a=max-size : 131072 



6. Reserve IP-CAN bearer for Media at terminating side 

The terminating CUA initiates media reservation. 

7. SIP INVITE request (from CSI AS to the terminating user CUA#2 in CS domain) 

Acting again as a B2B UA the CSI AS substitutes the SIP URI in the Request URI (received in step 3) with a 
Tel URI and initiates a new INVITE request. See example in Table B.8.2-5. 



Table B.8.2-5: INVITE request (CSI AS as B2BUA to S-CSCF#2 for CS call) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2.0 as.home.net; branch=z9hG4bKnashdt8t8 

Max-Forwards : 65 

Route: <sip : scscf 2 . home2 . net>, <sip : bgcf . home2 . net> 

Record-Route: <sip: as .home2 . net> 

P-Asserted-Identity: <tel: +l-212-555-3333> 

P-Access-Network-Inf o : 

Privacy: none 

From: <tel: +l-212-555-3333>; tag=171828 

To: <tel:+l-212-555-2222> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

Contact: < sip: [5555 :: aaa:bbb: ccc : ddd] : 1357; comp=sigcomp > 

Accept-Contact: *, +g . 3gpp . cs-voice, +g. 3gpp. cs-video; explicit 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

C=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 
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a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp : 97 mode-set=0, 2,5,7; mo de- change -period=2 

a=rtpmap: 96 telephone-event 

a=maxpt ime : 2 



8. ISUP lAM (from the MGCF to the VMSC of the terminating CUA#2) 

The MGCF performs the IMS/CS interworking functions and initiates an ISUP lAM towards the VMSC. 
Because the media for the originating side is not yet available, the MGCF indicates "Continuity check performed 
on previous circuit" in the lAM. 

Editor's note: Work is needed to resolve the topic of provision of CSI related information of Radio Environment 

Capability, IM Status, Personal ME Identifier, UE Capability Version ove the CS domain by the CSI AS. 
Without MGCF interworking support for transport of such information study resolution is needed as to 
how or if it is at all possible that such information can be provided to the CUA#2. 

9. H248 interactions (between MGCF and MGW) 

MGCF interacts with MGW for necessary resource allocation. 

10. SIP 200 (OK) response (from CUA#2 back to CSI AS through intermediate IM CN subsystem #2) 

After reserving an IP-CAN bearer for the message session media component the terminating CUA sends a 200 
(OK) response for the INVITE request containing SDP that indicates that the terminating CUA has accepted the 
message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP 
from the originating CUA. 

CUA#2 declares support only for CS-voice, not CS-video in its Contact header. The terminating CUA includes 
its personal ME identifier and UE capability version in the service header. 

See example in Table B.8.2-6. 

Table B.8.2-6: 200 (OK) response (CUA#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 
Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>>, <sip: scscf2 . home 2 .net; lr>. 
Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <tel: +l-212-555-3333>; tag=171828 
To: <tel:+l-212-555-2222>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Contact: <sip: [5555: :eee:fff:aaa: bbb] : 8 805; comp=sigcomp>; +g . 3gpp . cs -voice 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Server: PMI-0EA2, UCV-08 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=0 

m=message 3402 TCP /MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp: // [5555: : eee : f f f : aaa : bbb] :3402/s234167;tcp 

a=max-size : 6553 6 



NOTE: The SDP contains the set of offered content types supported by CUA#2 and desired by the user at CUA#2 
for this session in the accept-types attribute and indicates the maximum size message that can be received 
by CUA#2 in the max-size attribute. 

11. SIP ACK request (CSI AS back to CUA#2) 
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The CSI AS provides SIP ACK request to CUA#2. 
12. SIP 183 (Session Progress) response (from MGCF to CSI AS through intermediate IM CN subsystem #2) 

The MGCF provides a 183 Session Progress request back to the CSI AS through S-CSCF#2. 
12a. SIP 183 (Session Progress) response (from CSI AS to UE#1) 

The CSI AS provides a 183 Session Progress response back to the UE#1. 

12a. SIP 183 (Session Progress) response (from CSI AS to UE#lthrough intermediate IM CN subsystems) 

CSI AS in turn provides 183 (Session Progress) response back to UE#1 through the intermediate IM CN 
subsystems. This 183 (Session progress) response from the CSI AS will include a SDP answer to UE#rs SDP 
offer in the initial INVITE. See example in Table B.8.2-7. 
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Table B.8.2-7: 183 (Session Progress) response (CSI AS to S-CSCF#2) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ; branch=z9hG4bK764z87 . 1, 

SIP/ 2 .0/UDP icscf 2„s .home2 . net ; branch=z9hG4bK871yl2 . 1, 

SIP/ 2 .0/UDP scscf 1 .home 1 . net ; branch=z9hG4bK332b23 . 1, 

SIP/ 2 .0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, 

SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>>, <sip: scscf2 . home 2 .net; lr>. 
Privacy: none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <tel: +l-212-555-3333>; tag=171828 
To: <tel:+l-212-555-2222> 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Contact: <sip: [5555: :eee:fff: aaa: bbb] : 8 805; comp=sigcomp>; +g. 3gpp. cs -voice 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, OPTIONS 
Server: PMI-0EA2, UCV-08 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555:: eee : f f f : aaa : bbb 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2, 5, 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 

c=IN IP6 5555 :: eee : fff: www: yyy 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp: // [5555: : eee : fff : aaa: bbb] :3402/s234167;tcp 

a=max-size : 6553 6 



13, 13a. SIP PRACK request (from UE#1) 

UE#1 upon receipt of 183 (Session Progress) response replies back with PRACK request. With that UE#1 
initiates resource allocation for the session it originated. 

14 Reserve IP-CAN bearer for Media at originating side 

The originating UE starts resource reservation for media bearers. 
15, 15a. SIP PRACK request (from CSI AS to MGCF) 

The PRACK from UE#1 lead the CSI AS to provide PRACK to the MGCF 
16,16a SIP 200 (OK) response (MGCF to CSI AS ) 

MGCF acknowledges the PRACK (from CSI AS) with 200 (OK) (back to CSI AS) 
17, 17a. SIP 200 (OK) response (from CSI AS to UE#1 through intermediate IM CN subsystems) 

CSI AS correspondingly provides the 200 (OK) back to UE#1 through the intermediate IM CN subsystems. 
18, 18a SIP UPDATE request (from UE#1 to CSI AS through intermediate IM CN subsystems) 

UE#1 indicates it has available the necessary resources. 
19, 19a SIP UPDATE request (from CSI AS to MGCF through intermediate IM CN subsystem#2) 

CSI AS provides the indication of available resources at originating side to the MGCF. 
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20. ISUP COT (from MGCF to VMSC) 

With the UPDATE indicating that originating side has the necessary media resources and as such conditions are 
met, the MGCF sends COT to the VMSC indicating "continuity check successful". 

21. SETUP (from VMSC to CUA#2) 

The VMSC now sends the SETUP towards the terminating CUA#2. 

22. CALL CONFIRM (from CUA#2 to VMSC) 

The terminating UE acknowledges and confirms acceptance of the incoming call by sending CONFRIM back to 
the VMSC. 

NOTE: There is no suggestion, by this example or otherwise, that CUA#2 only response with CALL CONFIRM 
after the INVITE for the IMS part is received. 

23. ALERTING (from CUA#2 to VMSC) 

For this example, the VMSC allows early local alerting. With the generation of local alerting, ALERTING is 
sent back from the UE to the VMSC. 

24. ACM, CFG, SIP 180 (Ringing) response and SIP Prack request (VMSC to MGCF through IM CN Subsystem 
to originating end) 

On receipt of the ALERTING from the terminating UE, the VMSC, MGCF, IM CN subsystem and the 
originating UE exchange ISUP and SIP signalhng to indicate that the called party confirmed the call and did start 
ringing the end user. 

25. 25a . Resource allocation (VMSC to terminating UE, MGW and VMCS) 

The VMSC starts resource allocation towards the terminating UE. 
Between VMSC and the MGW resource allocation is also started. 

26. CONNECT (from CUA#2 toVMSC) 

When the user answers the call, the terminating UE sends CONNECT to the VMSC. After sending the 
CONNECT, the terminating UE is ready to connect to user plane resources. 

27. CONNECT ACK (from VMCS to CUA#2) 

VMSC connects up the user plane and return CONNECT_ACKNOWLEDGE to the terminating UE.. 
Through connect all the way back to originating UE is not initiated. 

28. ANM (from VMSC to MGCF) 

The VMSC having through connected the user plane sends an indication of answer to the MGCF. This is the 
ISUP ANM message. 

29. SIP 200 (OK) response (from MGCF to the CSI AS via the intermediate IM CN subsystem #2) 

Upon the receipt of the ANM from the VMSC, and after the connection of the media flow, the MGCF sends the 
SIP 200 (OK) final response to the received SIP INVITE request (in step 5) back to the CSI AS via the 
intermediate IM CN subsystem #2. 

30. 30a . SIP 200 (OK) response (from CSI AS to intermediate IM CN subsystem #2) 

The SIP 200 (OK) final response is provided by the CSI AS back to the originating UE#1 through the 
terminating intermediate IM CN subsystem #2. 

NOTE: In this example, the CSI AS provides the 200 (OK) response back to the originating UE#1 after both the 
voice session and the session containing the MRSP have been successful established. 

31. 31a. SIP ACK (from UE#1 to CSI AS through intermediate IM CN subsystems) 
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UE#1 responds to the 200 (OK) with ACK 
32, 32a. SIP ACK (CSI AS to MGCF) 

The CSI AS correspondingly provides the ACK to the MGCF. 
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